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Abstract. We propose a light-weight client-server model of communica¬ 
tion between existing implementations of different program analyses. The 
communication is on-line and anonymous which means that all analyses 
simultaneously analyse the same program and an analysis does not know 
what other analyses participate in the communication. The anonymity 
and model’s strong emphasis on independence of analyses allow to pre¬ 
serve almost everything in existing implementations. An analysis only 
has to add an implementation of a proposed communication protocol, 
determine places in its code where information from others would help, 
and then check whether there is no communication scenario, which would 
corrupt its result. We demonstrate functionality and effectiveness of the 
proposed communication model in a detailed case study with three anal¬ 
yses: two abstract interpreters and the classic symbolic execution. Re¬ 
sults of the evaluation on SV-GOMP benchmarks show impressive im¬ 
provements in computed invariants and increased counts of successfully 
analysed benchmarks. 

Keywords: Communication, program analysis, anonymous, online. Apron, 
Box, Polka, Symbolic execution. 


1 Introduction 

Our experience with several program analysis tools suggests that a piece of in¬ 
formation provided to an analysis at a right place may (substantially) improve 
its result. Although it is usually not difficult to identify such places (e.g. evalua¬ 
tion of highly over-approximated program operators, like bit-operators, pointer 
arithmetic, etc.) a problem is where to get the information. The additional in¬ 
formation may be known to another program analysis. 

We propose a light-weight communication model allowing a program analysis 
to issue a query to other analyses (analysing the same program in the same time) 
for an additional information which might hopefully push it towards to a better 
result. The communication is in the style client-server. The server mediates the 
communication between individual analyses (clients). Each client performs his 
work on his own private data (like internal program representation, memory 



model, etc.). Nevertheless, the communication itself has to be performed in term 
all clients understand. Client’s query thus typically begins with a conversion of 
his internal data to common terms, and it ends by the opposite conversion. 

The proposed communication model is based on the following key features 
which together distinguishes our work from previous approaches in the field: 

— Independence of clients: Each client implements his communication protocol 
without consideration of other clients. This implies that in order to add a 
new client into the communication, implementations of all former clients 
remain exactly the same, i.e. no line of code has to be changed, added, 
or removed. Also, if we have n > 0 clients with their communication code 
already established, then code of no client has to be changed in order to run 
any of 2” — 1 their possible combinations. 

— Asynchronous execution of clients: The communication model casts no re¬ 
quirements for synchronization of computational steps of clients. It means 
that some clients may perform forward analysis, other backward, and even 
speed in which different clients explore their internal program representa¬ 
tions may differ. 

~ Reuse of current implementations: The model attempts to preserve both al¬ 
gorithms and related data structures of analyses which clients perform. So, 
there is no need for their re-implementations. A client only has to add an 
implementation of the communication protocol, determine places in its code 
where to use information from others, and check that there is no communi¬ 
cation scenario which would corrupt his results. 

An important part of the paper is also the case study, which represents the 
first instance of the proposed communication model. There are three clients in 
the case study. Two of them perform “intervals” and “polyhedrons” abstract 
interpretations [7] and the third is the classic symbolic execution [TB]. The de¬ 
scription of the case study in this paper serves as a detailed example. It is meant 
to be used as guide for building other instances of the model. The evaluation 
of the case study was performed on SV-COMP [50] benchmarks for five combi¬ 
nations of clients. Results of individual combination were compared per client 
in terms of strengthened invariants (for abstract interpreters) and impact of the 
communication on success/fail termination states (for all clients). Although re¬ 
sults of individual configurations are quite impressive for themselves, we further 
observed that each configuration can actually bring as not negligible improve¬ 
ments over others. This opens a new (originally unexpected) application of the 
approach: Given n > 0 clients and a program to be analysed, we build as many 
combinations from all 2" — 1 as possible (we are only limited by resources, like 
number of computers, threads, time, etc.) and we analyse the program for each 
of them. Then we merge all results. 

We explain the communication model in Sec. We first describe common 
terms in which the communication is performed and then we present communi¬ 
cation protocols for clients and the server. The case study is presented in Sec. 

It starts with a description of all three clients and the rest is dedicated to a 
detailed evaluation. 
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2 Communication model 


A client is a program analysis tool or a program analysis inside a tool which 
is able to communicate with other clients during analysis of a given program. 
A server is a program utility mediating the communication between clients. A 
client can only communicate with the server and has no information about other 
clients, except their count. Data exchanged between the server and a client are 
received in exactly the same order as they are sent. There is a time-out for 
whole the communication common to all clients and the server. There is a single 
program analysed by all clients. 

Given a program written in a certain programming language, a concrete pro¬ 
gram state is an element of the concrete semantics of the language, an abstract 
state space is any subset of a client’s interpretation (e.g. abstraction or gener¬ 
alisation) of the semantics of the language, and an abstract program state is an 
element of an abstract state space. 

Let us suppose a client receives an information from other clients (via the 
server) that “at address 1234 there is stored an integer greater than zero”. This 
information is useless for the client until it is coupled with the following: 

1. An actual value of the instruction counter. 

2. A set of program paths (from the program’s entry to the actual instruction 
counter) for which the information was inferred. 

3. A meaning of the address 1234 in order to map it into a particular address 
in client’s representation of program’s memory. 

Points 1. and 2. are discussed in Sec. |2.1[ the point 3. in Sec. |2.2| and a 
concrete structure of the received information in Sec. 12.31 The communication is 
described in Sec. |2.3| and |2.4| as client’s and server’s communication protocols. 

2.1 Canonical program 

Given a program written in a certain programming language, a canonical program 
is a model of program’s instruction counter designed and used by clients for 
purposes of their communication. Before start of the communication each client 
must have his copy of the canonical program. 

There is a program representation which is very popular among clients: a 
control-flow graph. We present a “default” recipe how clients may build a canon¬ 
ical program from a control-flow graph of an elected client. Clients may later 
separate the resulting implementation into a stand-alone utility program. 

We assume in the recipe that the input control-flow graph satisfies the fol¬ 
lowing properties (which might require some pre- and/or post-processes of a raw 
control-flow graph produced by the client): 

— The instruction counter is modeled by nodes and edges represent possible 
transitions of the counter during execution of the program. 

— Each sub-program is represented by a separate component with a single entry 
node and a single exit node. 
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(f) 


Fig. 1. (a) Five C samples and indices of their lexical tokens, (b)-(f) A possible canon¬ 
ical program for samples 1-5 respectively. Labels on edges represent back-mapping of 
the input control-flow graph and labels inside nodes represent the labeling in the final 
canonical program. Note that (b) shows 2 possible versions of a canonical program. 


— The control-flow graph is coupled with a set of all edges representing calls 
of sub-programs. Let us denote it “set of calls”. 

— The control-flow graph was constructed on a syntactically reshaped version 
of the original program, where each lexical token was put into a separate 
line. For C programs there are tools available for this functionality including 
computation of the back-mapping of lines to the original program 

This reshaping is used to achieve one-to-one mapping between program lines 
and indices of lexical tokens (since these indices may not be directly available 
to a client). In Fig. (a) there are five C samples with tokens indexed. In 
the reshaped program these indices are equal to program lines. 

— The control-flow graph is coupled with a “back-mapping” to the reshaped 
source code of the analysed program, which maps each edge to a set of all 
those program lines (i.e. lexical tokens) s.t. an effect of the code at those lines 
is associated with the edge. It does not imply that index of every program’s 
token must appear in the range of the back-mapping. Typically, indices of 
tokens whose purpose is captured by the shape of the control-flow graph 
(e.g. semicolons, some brackets, keywords like if, else, for, etc.) must not 
appear in the back-mapping. Such conventions are dependent on agreement 
of clients. We require the back-mapping has the following property: If two 
edges have non-empty intersection of their sets of lines, then the edges have 
the same head node. Back-mappings for all 5 samples of Fig. (a) are de¬ 
picted in Fig. (b)-(f) as labels of edges. Please, ignore labels of nodes. A 
code associated with an edge may consist of one or more statements (e.g. a 
sequence of assignments, whole if-then-else statement, or even several 
loops). This level of details is given by the input control-flow graph. Of 
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course, more detailed control-flow graphs are preferable. For sample 1 we 
present at Fig. (b) a detailed version (left) and a coarse one (right). 

The recipe proceeds in the following three steps: 

1. Discard all labels of all nodes and edges of the control-flow graph. 

2. Label each edge in the set of calls as call edge and label each edge with an 
out-degree greater then 1 as branching edge. 

3. Label each node by a set of indices of program’s lexical tokens. We compute 
node’s label as the union of values of the back-mapping function for each 
out-edge from the node. 

Observe that labels of exit nodes of all sub-programs are necessarily empty. 
Now we can define meaning of a node of a canonical program: 

A statement that the instruction counter is at a certain node of a canonical 
program means that the instruction counter is at the position in the source code 
s.t. all lines of an instruction to be executed next belong to the label of the node. 


Canonical programs for all five samples of Fig.[^(a) are depicted in Fig.[^(b)- 
(f) (please ignore labels of edges; labels of branching edges are omitted). 

In the remainder of the paper we use the term node as a representation of a 
concrete value of the instructions counter in a canonical program. Similarly, we 
use the term edge for a possible transition of the counter between nodes. Finally, 
we distinguish two kinds of edges: call and branching, with obvious meanings. 


Mapping between canonical and internal program representation 

Another important purpose of labels of canonical program’s nodes is to allow 
individual clients to build a mapping between nodes of the canonical program 
and their own internal program representations (on which analyses are actu¬ 
ally performed). A construction of such mapping requires that all clients build 
their internal program representations from the reshaped program instead of 
the original one. Not all nodes of the canonical program has to appear in the 
mapping. Nevertheless, a client should attempt to establish the mapping for as 
much nodes as possible, since he may issue communication queries (or provide 
a useful information to others) only at nodes with the mapping. 

Since labels of nodes of a canonical program partition all tokens of the pro¬ 
gram (possibly expect some auxiliary tokens as mentioned above), clients may 
store only incomplete information about program lines in their internal program 
representations. This information may differ from client to client. For example, 
given a C statement a=0; one client may identify it only by the line of its first 
token, i.e. the line of a, another by the line of the last token, i.e. of 0 (or even 
of ;), and another by the line of the root operator, i.e. of =. Moreover, client 
may perform several equivalent program transformations, e.g. code optimisa¬ 
tions. Consider for example a client which first translates a C program to LLVM 
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assembly with several optimisations enabled, and then he builds his internal pro¬ 
gram representation from the optimised assembly. Such transformation typically 
reduce information about program lines. 

It is very difficult (or impossible) to provide a general algorithm for construc¬ 
tion of such mapping, since internal program representation of a client may be 
arbitrary. Here we provide a “default” recipe for construction of the mapping 
for clients whose internal program representation has a form of a control-flow 
graph in which nodes model the instruction counter: 

Let {h,t) be an edge of an internal program representation s.t. there is a 
source code line associated with the edge, and let n be a node of the canonical 
program containing the line in its label. We extend the mapping in any of the 
following three cases: 


1. If in-degrees of both n and h are zeros, then link h with n. 

2. If t is an exit node and n has a successor with the empty label and with the 
out-degree 0, then link t with the successor of n. 

3. If all successor edges of t have lines associated and all the lines belong to 
the label of a single successors node n' of the node n and n ^ n', then link 
t with n!. 

We demonstrate an application of the recipe in an example depicted in Fig. 


Context 

A filter is a set of kinds of edges of a canonical program (remember that we 
distinguish only two kinds of edges in this presentation). A context is a list of 
edges of a canonical program s.t. each edge has a kind which belongs to a given 
filter. For example, any context constructed for the filter {call} may contain only 
call edges. 

A context constructed for a certain filter represents a set of program paths 
starting at the program’s entry node. A path belongs to the set if and only if 
the context is equal to a list of edges constructed from the path s.t. each edge 
with a kind belonging to the filter is preserved and any other is removed. 

A context coupled with a node represents the set of its paths restricted to 
those terminating at the node. 

We demonstrate of a meaning of a pair “node,context” on example canonical 
program in Fig[^ (b) constructed for the C function in Fig[^ (a). We consider 
several contexts coupled with the same node labeled by {13..15}. We list the 
contexts in the following table together with their creation filters and with de¬ 
scription of set of paths they represent: 
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int^ btree.contains^(®int^ key® ,®btree_node^*® node®)^'^{^^ 

intl2 .13^14015.16 
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return^o 

return"® btree.contains"" ("®key"6 , node"®->"0child3“ + 83 ^ 84385 ) 86.87 


(a) 




Fig. 2. A mapping between a canonical program (b) and an internal program repre¬ 
sentation (c) both constructed for a C function (a) with tokens indexed. In (b) ignore 
numbers labeling edges and labels B and C stand for branching and call kinds re¬ 
spectively. (c) references the source code (a) via indices of root tokens of program 
expressions (see bolt numbers labeling edges). Links between nodes of (b) and (c) were 
computed by the default recipe. Namely, the link *1 was set according to the case 1, 
links *2, *3, *4, according to the case 2, and all others according to the case 3. 


Context 

Filter 

Descritption 

[] 

[6,6,6,6] 

[1,2,1,2,3,4,5,6] 

0 

{call} 

{call, branching} 

All paths reaching the node. 

All possible paths to the node performing 4 
recursive calls btree_contains"". 

The path looping twice in the while"" 
loop, then taking false branches of both 
if^" and if®" (without evaluation of 
==®") and then applying the recusrice call 
btree_contains"". 


Since client’s mapping between a canonical program and an internal program 
representation may be only partial, it may be impossible for the client to create 
some contexts. For example, if the tail node of some branching edge is not 
mapped, then the client cannot create a context for a filter with branching edges 
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kind representing program paths passing only through that edge. Therefore, 
properties of client’s analysis (like call-sensitivity or path-sensitivity) may not 
always be reflected in the communication through contexts due to incompleteness 
of the mapping. 

Let us return back to the example above. Now we try to translate the node 
(labeled by {13..15}) and all three contexts in the table to the internal program 
representation in Fig. (c). The link *1 allow as to move from the node of the 
canonical program to the corresponding node in the internal program represen¬ 
tation. In this case we move to the entry node. Note that in case there is no link 
for the node then we could not continue with the example. 

The first context [] can be translated without any loss of accuracy, i.e. the 
set of path represented by the context does not have to be extended. The reason 
is simple, the context represents all paths from the programs entry up to our 
translated entry node (including any number of recursive calls, etc.). 

The second context [6, 6, 6,6] can also be translated without a loss of accu¬ 
racy. That is because links *10 and *4 uniquely map the edge 6 to the path 
consisting of two edges associated the line 74 and just one of then is the call 
edge. The call site is thus uniquely identified. 

The third context [1, 2,1, 2, 3,4,5,6] contains edges, namely 3, 4, and 5, which 
cannot be translated to the internal program representation, since we do not have 
links for tail nodes of the edges 3 and 4. So, we have to reduce the context into 
[1, 2,1,2,6]. Now we can translate all edges: Edges 1 and 2 of the loop translate 
to edges with lines 20 and 31 in the corresponding loop (we used links *5, *6, 
and *7 for the translation), and the edge 6 is translated the same way as for 
the second context. In terms of the canonical program (Fig. (b)) the reduced 
context [1,2,1,2,6] extend the set of paths over the original one (as described 
in the table) by those paths which go through the node labeled by {45..52}. 
Nevertheless, if we look into the internal program representation (Fig. i(c)). 
then both the original and the reduced context represent the same set of paths, 
because of the optimised shape of the program representation. Namely, there is 
only one possible path from the loop (left along the edge with the line 20) to the 
call site. Therefore, a reduction of a context does not necessary implied a loss of 
precision. 

Now we look at the opposite direction. We consider the following path in 
the internal program representation expressed in term of lines labeling edges: 
[14,20,31,34,20,31,34,20,67,67,74]. We now translate this path to the canonical 
program in a form of a context constructed for a filter the filter {call, branching}. 
The edge 14 can be translated to the canonical program, since we have links *1 
and *5. Nevertheless, the corresponding edge is neither call nor branching edge 
in the canonical program. So, we skip it. Edges 20 and 31 can be translated 
to branching edges 1 and 2 respectively. We further skip both edges 34 for the 
same reason as for the edge 14. Next, the edge 20 and both edges 67 cannot 
be mapped because of lack of links between nodes. And the call edge 74 can be 
mapped to the call edge 6. Therefore, we end up with the context [1,2,1,2,6]. 
This is the reduced context we discussed above. Observe that we were unable to 


reconstruct the more precise context [1, 2,1, 2, 3,4, 5,6] due to lack of mapping 
between nodes. 

Finally, observe that the exit node of the canonical program is mapped to 
three exit nodes of the internal program representation. So, if we want to trans¬ 
late a pair “the exit node, context” to the internal program representation, 
then we may get three translated pairs “node* 2 ,context'”, “node^g,context'”, 
and “node^ 4 ,context'”, which are supposed to be considered together (as union). 

Now we define a special form of context reduction using a filter. Given a 
context and a hlter, a reduced context by the filter is constructed from the given 
context s.t. each edge whose kind does not belong to the intersection of the filter 
and the construction hlter of the context is removed. 

Multi-threading Different threads may be distinguished through a context: A 
construct which causes a creation of a new thread can be modeled in a canonical 
program by an artihcially introduced branching (e.g. by two parallel edges). 
Clients may decide to use special labels and hlters for these edges. We do not 
introduce them, because they are not necessary in further presentation. 


2.2 Canonical memory 


Given a program written in a certain programming language, a canonical mem¬ 
ory is a model of program’s memory designed and used by clients for purposes of 
their communication. Organisation of memory may differ signihcantly for differ¬ 
ent languages, consider for example C and Prolog. Here we provide a “default” 
canonical memory where we model only address space and dereferences of ad¬ 
dresses (which is sufficient for purposes of communication). The model is thus 
very low-level. 

Addressing of program’s memory is based on the common segment-offset 
style. Given a program and an ordered list of all its identihers referencing mem- 
orjj^a segment is any integer between 0 and the number of identihers in the list. 
The segment 0 is reserved for modeling of the standard invalid memory, repre¬ 
sented by the NULL pointer in some languages. Other segments represent indices 
of identihers in the list. We recommend to order identihers in the list according 
to their token-indices (each identiher is also a lexical token), since there can be 
several identihers with the same name. An offset is any non-negative integer. 

A sequence of bytes starting at a given segment and offset can have any of 
the following type interpretations: 


i8, il6, i32, 164 
u8, ul6, u32, u64 
f32, f64 
seg, off 


A signed 8,16,32,64-bit integer. 

An unsigned 8,16,32,64-bit integer. 

A 32,64-bit hoating point number. 

A representation of addresses (pointers). 


A concrete encoding of these types is given either by the program’s deployment 
machine, or on a mutual agreement of clients, seg and off should be encoded 

^ Using the terminology of C language: All those which may be used as 1-values. 
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as unsigned integers big enough to capture available address space. Data of 
composed types can be communicated with other clients only after their decom¬ 
position to elements of basic types above. 

A dereference is a triple consisting of a segment expression, an offset expres¬ 
sion, and a type. A segment expression is either a segment, or a dereference of 
the type seg. An offset expression is any integer expression over integer con¬ 
stants, interpreted functions for addition, multiplication, etc., and over deref¬ 
erences of either any integer type or the type off. A dereference represents a 
type-interpreted values of bytes pointed to by its segment and offset expressions. 
A dereference is called basic if neither segment nor offset expression contains any 
dereference. 

A value in the memory referenced by a program identifier is directly denoted 
by a basic dereference. A value stored in a non-leaked memory in the program’s 
heap can always be referenced by a finite sequence of dereferences starting with 
a certain program identifier. The sequence can always be expressed by nesting 
of dereferences inside segment and offset expressions of a non-basic dereference. 
Memory of a record on the top of the program’s call stack is directly read by 
basic dereferences. Memory of the records deeper in the stack is accessed via 
non-basic dereferences exactly the same way as the memory in the program’s 
heap. 


void fooCint** p) {} 
void mainO { 

int* p=(int*)malloc(100); 
foo(&p); 
free(p); 

} 

(a) 


Identifier 

Segment 

foo 

1 

foo::p 

2 

main 

3 

main: :p 

4 

(b) 



Dereference 

Description 

(2, 0, seg) 

Segment of an address stored in foo: :p. 

(2, 0, off) 

Offset of an address stored in foo: :p. 

((2,0, seg), (2,0, off), seg) 

Segment of an address stored in main: :p. 

((2,0, seg), (2,0, off), off) 

Offset of an address stored in main: :p. 

(((2, 0, seg), (2, 0, off), seg), 
((2,0,segX (2,0, off),off) -|- 12, 

i32) 

A value of the fourth element of the allo¬ 
cated array (we assume sizeof (int)==4). 


(c) 


Fig. 3. Example for dereferences: (a) C program to be considered, (b) An ordered list 
of program’s identifiers and a mapping to segments, (c) Five dereferences and their 
descriptions. It is assumed the instruction counter is inside the function foo. 
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Note that threads do not have to be considered here, since they may be 
distinguished through a context (see page|^. In Fig. there is an example how 
a canonical memory is used. 

2.3 Client’s side of the communication protocol 

Client’s communication protocol is a specification of six functions. A client has 
to implement each of them. The specifications are the following: 

get_values(node,context,dereferences,self_call) -> formula 

A client is queried for a superset of all concrete program states represented 
by all his abstract states related to the node and the context. In other words, 
the client is queries for an over-approximation of his current knowledge about 
program’s behaviour regarding the node and the context. 

The passed dereferences can be used to determine what superset will be 
computed. Typically, knowledge in the abstract states about memory addressed 
by no dereference in dereferences is ignored. For example, let us suppose that 
program variables a and b are presented by basic dereferences (2, 0, 132) and 
(3, 0, 132) respectively, and dereferences = {(2, 0,132)}. Then the client may 
ignore his knowledge about (3, 0, 132) when computing an answer to the query. 
On the other hand, if client’s knowledge about a is expressed in a form of a 
constraint over several variables, like a -f 2(b — 3) < 0, then (3, 0, 132) can be 
considered for the answer as well. 

The superset is then encoded as a quantifier-free first order logic formula over 
dereferences in a standard format all client agreed on, e.g. SMT-LIB2 [25]. Any 
such formula may only contain interpreted symbols from theories of integers, 
Peano’s arithmetic, and reals. The only uninterpreted symbols are related to 
dereferences: A dereference with a segment expression s, an offset expression 
o, and a type t is encoded as an application of a binary uninterpreted function 
DEREFT to arguments s and o. It is not necessary to provide declarations of these 
uninterpreted functions, since all clients know their exact meanings. Returning 
back to the example above, client’s answer in SMT-LIB2 format may look like 
this: (< (+ (+ (DEREF_132 2 0) (* 2 (DEREF_132 3 0))) (- 6)) 0). 

It is further highly recommended for clients to agree on additional syntacti¬ 
cal restrictions for formulae. They should not restrict expressivity, they should 
ease decoding of answers. Clients may for example consider these: The formula 
is in DNF, right hand side of any (in)equality is always a numeric constant, 
distributive laws are applied where possible, constant expressions are simplified, 
no use of binary subtractions, etc. The last tree restrictions were applied in the 
example above. 

If the client does not have established the mapping for the passed node, then 
he returns a simple tautology, e.g. (= 1 1). 

The argument self_call is true if the client is the one who initiated the 
query. Otherwise it is false. 

get_coverage(node,context) -> coverage 
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A client is supposed to compute a real number between 0 and 1. This number 
represents a measure, how much the current client’s abstract state space covers 
the set of all concrete program states determined by the node and the context. 
The value 0 means that the client covers no concrete state and the value 1 means 
that all concrete states are covered. Values in-between 0 and 1 can be computed 
from a progress observed in the abstract state space from the start of the analysis 
up to the current time point. We provide more details in Sec. |2.7[ 

The client returns 0, if he does not have established the mapping for the 
passed node. 

is_relevant_coverage(node,context,coverage,self_coverage) -> bool 
A client is asked whether coverage computed by some other client is big 
enough so that this client would accept result of a call to the function get_values 
of the other client. Clearly, the client returns false whenever coverage is 0. 
The argument self _coverage is the result of the function get_coverage of this 
client. This values may be useful for the client to make the decision. We provide 
more details to the decision in Sec. 12.71 

The client returns false, if he does not have established the mapping for the 
passed node. 

is_memory_over_approximated() -> bool 

A client is supposed to return false if any of the following cases: 

1. The client has updated an abstract state but he has not send a notification 
on_location_outdated to the server about the update yet. 

2. Client’s function can_improve_memory_over_approximation returns true. 

Otherwise, the client returns true. Observe that the function may return true 
even though client’s abstract state space currently does not expresses all possible 
behaviour of the analysed program. This may happen when client’s computation 
used values from other clients (via get_values) for coverages less then 1. 

can_improve_memory_over_approximation() -> bool 

A client returns true if he sees a chance in making a progress towards ex¬ 
pressing all possible behaviour of the analysed program. Otherwise, he returns 
false. Note that the answer true does not imply the client will necessarily ever 
do such a progress. 

on_location_outdated(node,context,coverage,self_call) -> none 

A client is notified through this function that abstract state space of some 
client has been updated. The node and the context provide a closer description 
what set of concrete program states the update was relevant for. 

The argument coverage is the result of the function get_coverage of the 
client who issued this notification on the updated version of his abstract state 
space. The argument self_call is true if the client is the one who issued the 
query. Otherwise it is false. 
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If the client does not have established the mapping for the passed node, he 
should perform a graph search in the canonical program to find all nearest reach¬ 
able nodes with mappings and apply the notification for each of them. Note that 
the context has to be extended/reduced for each node separately using client 
filter by considering all paths between the passed and the searched node. 

A passed context to some of the protocol functions may contain edges whose 
nodes do not appear in the mapping between the canonical program and client’s 
internal program representation. Such edges has to be removed. This removal 
may produce a context representing a larger set of program paths. Nevertheless, 
clients computation in protocol functions must be based on such larger contexts. 

All protocol functions above are supposed to terminate quickly. We cannot 
give exact complexities, but each of them should terminate (much) sooner than 
client’s algorithm which transforms an abstract state along a program’s edge. 

If an evaluation of any function above does not finish before the time-out, 
then the client may cancel its evaluation without sending any response to the 
server. Also, any queries from the server issued after the time-out may be ignored. 

A client may assume correctness of data received from other clients in in¬ 
dividual queries. He may also assume other clients meet all requirements given 
in this section. And he may further assume the server meets all requirements 
given in the section below. But he cannot make any other assumptions about 
the communication. It means that based on the mentioned assumptions he has 
to check by himself for the correctness of implementations of his communication 
related code in isolation from others by considering all possible scenarios how 
the communication may affects his results and performance. 

2.4 Server’s side of the communication protocol 

Server’s communication protocol is a specification of four functions. A server has 
to implement each of them. The specifications are the following: 

get_values(node,context,trace,dereferences,client) -> formula 

A client client calls this function in order to receive a knowledge about 
memory content from all clients. The server handles the query as follows: 

1 formula := client.get_values(node,context,dereferences,true) 

2 covO := client.get_coverage(node,context) 

3 for every other client C do 

4 cov := C.get_coverage(node,context) 

5 if client.is_relevant_coverage(node,context,cov,covO)) then 

6 F := C.get_values(node,context,dereferences,false) 

8 formula := make_conjunction(formula,F) 

9 return formula 

The use of conjunction as the connective between formulae has the meaning of 
intersection of sets of concrete program states represented by the formulae. 
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is_memory_over_approximated() -> bool 

A client calls this function in order to check whether abstract state spaces of 
all clients caver all possible behaviour of the analysed program. The server han¬ 
dles the query by invoking functions is_memory_over_approximated of all clients 
and returns true if all the clients respond by true and no on_location_outdated 
query is being evaluated during evaluation of this query. Otherwise, false is re¬ 
turned. 

can_improve_memory_over_approximation() -> bool 

A client calls this function in order to check whether at least one client can 
hopefully get his abstract state spaces closer to complete coverage of all possible 
behaviour of the analysed program. The server handles the query by invoking 
functions CcUi_improve_memory_over_approximation of all clients and returns 
true if at least one client respond by true. Otherwise, false is returned. 

on_location_outdated(node,context,coverage,client) -> none 

A client has to calls this function in order to notify others about the fact that 
his abstract state space has been updated. The passed client is the one who 
issues the notification. The node and the context provide a closer description 
what set of concrete program states the update is relevant for. The server is 
responsible for delivering the notification to all clients. So, the server invokes 
functions on_location_outdated of all clients with the last argument true in 
case of the client and with false for all other clients. 

A client may call any of these function any time before the time-out. If an 
evaluation of a query does not finish before the time-out the server may cancel 
the evaluation without any response to any client. Also, queries issued after the 
time-out may be ignored by the server. 

2.5 Issuing get_values for highly over-approximated operators 

Although it is completely up to a client to decide where and when to issue 
get_values queries, there is rather general scenario for recommended application 
of such queries: It is quite common that a client highly over-approximates effects 
of some language operators. Consider for example C language and bit-operators 
(like conjunction, negation, etc.), pointer arithmetic, or some math functions 
(like sqrt, pow, sin, etc.). The client may take advantage of the communication 
to improve the precision. We demonstrate this on a the following simple example. 

Let us consider a client who does not support pointers and who is about 
to execute a C assignment i=*p, where i and p have types int and int* 
respectively. Although the client cannot evaluate the sub-expression p (since 
it is a pointer), he can issue a query to other clients. Let us say the answer 
is (and (= (DEREF_seg 2 0) 3) (= (DEREF_off 2 0) 4)), where we assume 
that p is mapped to the segment 2. If the basic dereference (3, 4, 132) corre¬ 
sponds to a program variable, j say, than the client may evaluate the assignment 
as it was i=j. Otherwise, the client may issue another query for the dereference 
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(3, 4, i32). A received answer represents (an over-approximation of) an 132 
value to be assigned to i. 

2.6 Decoding answers from get_values can loose precision 

A formula returned from a get_values query may encode an information whose 
precision is beyond expressivity of client’s abstract state space. In any such case a 
lose of precision is inevitable. Another source of the lose can lie in an incomplete 
implementation of client’s decoding procedure. Indeed, a returned formula can be 
arbitrarily complex. A useful information may be encoded in several transitively 
dependent constraints. Client’s decoding procedure may simply ignore them. It 
is worth noting that a complete implementation of the decoding may lead to a 
non-trivial programming effort. 

We show this on the example from the previous sub-section, where we suppose 
the client performs the classic interval analysis and we consider the situation 
when the client receives an answer for the second query, i.e. for the dereference 
(3, 4, i32). Possible answers for the query may look like these: 

- (= (DEREF_i32 3 4) 3) 

- (and (< (- (DEREF_i32 34)) (-3)) (< (DEREF_i32 3 4) 10)) 

- (or (< (DEREF_i32 3 4) 3) (= (DEREF_i32 3 4) 10)) 

- (= (+ (* 2 (DEREF_i32 3 4)) (DEREF_i32 4 0)) 10) 

Although all of these formulae can be converted to intervals, the client may 
decide to restrict implementation of his decoding procedure to first two formulae, 
since decoding of others would lead to a loss of precision anyway. Therefore, the 
last two formulae are decoded as they are tautologies (i.e. any possible value). 

2.7 Coverage oracle 

Client’s protocol functions get_coverage and is_relevant_coverage require 
an estimation of how many concrete program states are represented by client’s 
current abstract state space. 

The estimation can be based on observation of progress of client’s abstract 
state space from the beginning of the analysis up to the current time. For a 
given node and context the client may for example observe changes in counts of 
abstract states, sizes of abstract states, or counts of updates of abstract states 
in time. In order to compute an estimate, the client needs to compare these 
“progress properties” with similar ones in client’s knowledge base. We can build 
a knowledge base for a client s.t. we run the client in isolation (i.e. without 
any communication) on a sufficiently large training set of benchmarks. For each 
benchmark the client observes a progress of his progress properties. Then we 
relate properties of analysed benchmarks (like number of tokens, number of 
loops, recursive functions, pointer dereferences, etc.) with functions from analy¬ 
sis time (scaled into the interval [0,1)) to the corresponding values of progress 
properties. In order to use the knowledge base the client need three functions. 
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A distance function between program properties, a distance function between 
progress properties, and a “progress” function which for a given program prop¬ 
erties and a passed (and scaled) analysis time finds a closed progress properties 
in the knowledge base. 

For get_coverage the client should extend the knowledge base s.t. progress 
properties are annotated by numbers between 0 and 1 representing coverages. 
This is possible, since the client has a complete information for each benchmark. 
The estimate (i.e. the resulting coverage) then corresponds to annotation of the 
closest progress properties in the knowledge base to the current ones. 

In case of is_relevcm.t_coverage the client uses his progress function to find 
a time for which the function returns closest properties to the current ones. The 
client tweaks the protocol function according to the time he found subtracted by 
the current time (scaled to [0,1)) in a way: bigger the result, higher coverages are 
accepted. The tweaking can ideally be sensitive to a passed node and context. 

2.8 Safety outdate 

There are situations which cannot be resolved only by functions get_coverage 
and is_relevcint_coverage. Let us consider a client whose goal is to compute 
an over-approximation of program’s behaviour and there is a part of his abstract 
state space (for some node and context) whose abstract states were computed 
from an information of other clients with coverages less than 1. The client cannot 
be satisfied with these states, if server’s query isjnemory_over_approximated 
returns false. It may happen the query remain false till the time-out. It may 
also happen that the client does not receive notifications on_location_outdated 
for that part of his abstract state space. 

In order to succeed in the computation of an over-approximation the client 
may force a re-computation of that part of the state space in sufficiently long 
time before the time-out. To prevent repetition of this situation in the subsequent 
computation the client may tweak his is_relevaiit_coverage function s.t. for 
the node and context of the problematic part of the state space only coverages 
1 are accepted. 

3 Case Study: Box, Polka, Symbolic execution 

In this case study we attempt to experimentally evaluate how much clients may 
ideally improve their results due to the communication. We thus investigate the 
limit case, where client are offered a maximal opportunities for the communica¬ 
tion: communication at each node, no overhead of message delivery, etc. 

We embedded three clients called Box, Polka, and Symbolic execution into 
a single tool [21]. The tool itself stands for the server. Clients are separate and 
completely independent modules in the tool, they can communicate only with 
the server through his protocol functions. The tool builds a single read-only 
internal program representation, which is referenced by all clients. The internal 
program representation simultaneously serves as a canonical program. Clients 
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may thus communicate at each node. Since all clients run on a single main 
thread, they perform their computations in small regularly interleaved steps. A 
step corresponds to an update of an abstract state space by taking one or more 
edges which all always share either head or tail node. A client determines by 
himself, i.e. independently to other clients, which edges he will take in what 
computation step. A client may issue communication queries to the server only 
during his step. Responses from other clients are also computed and returned in 
that step. This process is purely sequential. 


3.1 Clients: Box and Polka 

These two clients have many things in common. First of all, implementations 
of their communication-related code is very similar. Also, they represent two 
instances of the abstract interpretation framework [7] . While Box uses intervals 
to represent a memory content. Polka uses polyhedrons. Moreover, both are 
implemented in the same library called Apron [21j . Therefore, we join their 
description here, but all differences are explicitly stated. 

Both clients are integrated into the tool in the default setting: Join operators 
are applied at each node with an in-degree greater then 1, widening operators 
are applied at each loop head and function entry node (because of recursion), 
and all heap allocations performed along the same edge are indistinguishable for 
the same context. Both clients perform call-sensitive analysis, and they construct 
contexts for filters consisting of call edges kind. 

Both clients issue queries to the server in same situations. Whenever a part 
of an abstract state space is updated the query on_location_outdated is issued. 
The query get_values is issued in two situations during a computational step 
of a client, when a source abstract state is supposed to be transformed along 
a program edge. First, instead of taking the source abstract state directly from 
the abstract state space there is used a result of get.values (after its transla¬ 
tion to an abstract state). Second, during evaluation of a program expression 
associated with the edge: When the client does not have enough information for 
an evaluation of some sub-expression (e.g. a pointer dereference), then the client 
asks other (e.g. for possible values of the pointer) and continues the evaluation 
with that information. 

In the following subsections we discuss those modules of these clients, which 
are related to the communication. 


Coverage oracle 

This module records statistical data about a progress of client’s abstract 
state space and it plays an important role in the implementation of the protocol 
function get_coverage. 

The oracle maintains a map from nodes and contexts to ordinal numbers of 
client’s computational steps in which the corresponding parts of the abstract 
state space were updated for the last. 
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Given a node, a context, and a count n of all passed computation steps 
(including the current one) the oracle computes the corresponding coverage as 
a number 1 — (0.25 * u + 0.75 * v)/n, where u is an average of all values in the 
map mapped to by the context (and any node), and v is the value in the map 
for the node and the context. The term was inferred experimentally. 


Safety outdate 

There are three actions which may be applied during the safety outdate: 

1. Tweaking of client’s function is_relevant_coverage s.t. it returns false 
for any coverage less then 1. 

2. Marking of all abstract states appearing in a list extended by the function 
on_location_outdated (see the description of the protocol function below) 
as to be recomputed. 

3. Marking of all abstract states in the current abstract state space to be re¬ 
computed. 

Until the safety outdate is applied, it can be triggered in the following cases: 

(a) If server’s function is_memory_over_approximated returns true, then ac¬ 
tions 1. and 2. are applied. 

(b) If server’s function can_improve_memory_over_approximation returns false, 
then actions 1. and 3. are applied. 

(c) Let m be a number of communicating clients, n be a number of nodes in the 
program, t be the time point of the time-out in milliseconds, and c be 250 
for Box and 500 for Polka. If the current time point is greater or equal to 
max{0, t — c • m • n}, then actions I. and 3. are applied. Both “max” terms 
were adjusted experimentally. 


Communication protocol 

Box and Polka implement the mandatory functions of the protocol as follows: 

get_values: The function hrst collects all abstract states relevant to the passed 
node and a reduced context computed from the passed context and the client’s 
hlter. An abstract state is a list of Apron’s linear constraints over dereferences 
(represented via strings in Apron). Each state is converted into a conjunction 
of predicates, where each predicate is a direct conversion of a constraint from 
Apron’s internal data structures. Subsequently, from each conjunction there are 
removed all predicates which are irrelevant to the passed set of dereferences. The 
function then returns a disjunction of the resulting conjunctions. 

get_coverage: For each abstract states relevant to the passed node and a 

reduced context computed from the passed context and the client’s filter it calls 
the coverage oracle with the node and the reduced context. When n is a number 
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of such states and Ci is a value returned by the oracle for the i-th state, then 
the function returns the value Tn.&yi{l,n\. The term was adjusted 

exp eriment ally. 

is_relevaiit_coverage: If the safety outdate was already applied, then it re¬ 
turns true only if the passed coverage is equal to 1. Otherwise, there is computed 
a scale for the passed self-coverage. The scale is initialised to 1 and according to 
each property the of the passed node it is multiplied by coefficients in this table: 


Client 

Loop head 

Function entry 

Return node 

Join node 

Box 

0.25 

0.25 

0.5 

0.25 

Polka 

0.5 

0.5 

0.75 

0.9 


The values were adjusted experimentally. The function returns true only if the 
passed coverage is greater or equal to the self-coverage multiplied by the scale. 

is_memory_over_approximated: Returns true when a fixed-point is reached, 
i.e. when there is no abstract state (identified by a node and context) to be 
updated. Otherwise, it returns false. 

can_improve_memory_over_approximation: Returns a negated value from the 
function is_memory_over.approximated. 

on_location_outdated; If this is not the self-call and a call to the function 
is_relevant_coverage for the passed coverage returns false, then the function 
adds all abstract states corresponding to the passed node and context to a list 
of “states for safety outdate” and then terminates. Otherwise, it marking all 
abstract states corresponding the passed node and context for a re-computation. 


Correctness 

The client (Box or Polka) claims that program’s behaviour was successfully 
over-approximated only if his function isjnemory.over.approximated return 
true and the safety outdate was applied. 

After application of the safety outdate only values with coverage equal to 
1 are accepted. If the safety outdate was triggered by the case (b) or (c), each 
abstract state was recomputed. Otherwise, the case (a) was triggered and so 
the server returned true from his function isanemory.over.approximated. The 
computation performed so far was thus based either on final memory over¬ 
approximations from other clients or on re-computed abstract states where the 
client rejected final values of others due to low coverages. 


3.2 Client: Symbolic Execution 

Symbolic execution |16j is similar to standard program execution. The key differ¬ 
ence is that while the standard program execution runs the program on concrete 
input data (numbers), the symbolic execution runs the program on symbols. 
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Each symbol represents a concrete, but yet unknown, input value. Executed 
program paths are recorded in a tree, where the root corresponds to the en¬ 
try node and a leaf node either represents a termination of the execution or it 
belongs into the exploration frontier, i.e. it remains to compute its successors. 

Erom the communication point of view it is important to mention that this 
technique attempts to explore all feasible program paths. This goal is achieved 
very rarely in practice, only for programs with finite and quite low number of 
such paths. Therefore, the technique primarily focuses on searching for defects 
and typically end up with an under-approximation of program’s behaviour. 

The client is integrated into the tool in the default setting: There is fixed the 
breadth-first exploration strategy of feasible program paths, the variable storage- 
referencing problem is resolved by branching, there is only one SMT solver used 
for SAT queries, and there is no cache in front of the solver. The filter of the 
client consist of both call and branching kinds of edges. 

In the following subsections we discuss only those modules of the client, which 
are related to the communication with others. 


Coverage oracle 

This module records statistical data about both a progress of client’s ab¬ 
stract state space and queries issued to the client. It serves as the key part in 
implementations of protocol functions get_values and get_coverage. 

The main part of the oracle is a map from node and context to triples 
(formula, num_state_updates, num_formula_updates). The component formula 
is a formula over dereferences, num_state_updates is a counter of updates of the 
triple, and num_formula_updates counts number of updates of the formula. 
Each triple is initialised as (true,0,0). 

The oracle is called at the end of each client’s step in order to reflect updates 
he made. Given a node and context related to some of client’s updates, the oracle 
performs the following three steps: First, he expresses all abstract states corre¬ 
sponding to the node and the context in a form of a formula over dereferences 
according to a process described in the next sub-section. Then, he searches in 
the map for a triple using the node and the context. Lastly, the triple is updated 
s.t. num_state_updates is incremented, and if the newly computed formula is 
not logically equal to formula in the triple, then formula is overwritten by the 
new one and the counter num_f ormula_updates is incremented. In the case the 
formula was updated in the triple whole the record is registered into a special 
queue, if it is not already there. The client extracts records of the queue regularly 
in each step with a delay 10s and issues the query on_location_outdated to the 
server. The delay prevents frequent notifications for nodes inside loops, where 
symbolic execution tends to cycle very quickly for long time. 

The oracle is called from function of client’s communication protocol. These 
functions query the oracle fro triples stored in the map. For each such query, if 
the searched triple has num_state_updates equal to 0, then the oracle automat- 
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ically performs its update according to the procedure above, before the triple is 
returned. 


Building of response formula 

Given a node, a context, and the filter of the client, the procedure first collects 
all abstract states attached to nodes of the client’s symbolic execution tree which 
are relevant to the given program node and a reduced context computed from 
the given context and the filter. Note that the client’s filter consists of both 
branching and call edge kinds, since symbolic execution is fully path and context 
sensitive. Also note that each collected abstract state consists of a mapping from 
dereferences to expressions over inpnt symbols and a quantifier-free conjunction 
of predicates over input symbols. 

For each abstract state there is constructed a formula, which is initialised 
as the conjunction of predicates of the state. Next, for each pair in the map of 
the state a new conjunct is added into the formula. This conjunct is an equality 
between the dereference and the expression of the pair. Then, each equality in the 
formula, which consists of a dereference and an input symbols, all occurrences of 
the symbol in the formula is replaced by the dereferences. Finally, each predicate 
in the formula which still contains any input symbol is removed from the formula. 

From formulae we computed for each collected abstract state we now bnild a 
resulting formula. The formula is a conjunction of predicates which are common 
to all computed formulae (according to logical equality) and the strongest in¬ 
equalities between dereferences and numerical constants deducible from all com¬ 
puted formulae. Although we attempt to find as many common predicates and 
inequalities as possible, we may early terminate the search in order to preserve 
performance of the whole query. 


Communication protocol 

The client implements the mandatory functions of the protocol as follows: 

get_values: The function queries the coverage oracle for a triple for the passed 
node and context and returns the component formula of the triple. 

get_coverage : If is_memory_over_approximated returns 1, the also this func¬ 
tion returns 1. Otherwise, it queries the coverage oracle for a triple for the passed 
node and context. The function then returns a coverage value computed accord¬ 
ing to the following experimentally established term 1 — where s 

and / stands for num_state_updates and num_formula_updates respectively. 

is_relevaiit_coverage: This function always returns false, since no informa¬ 
tion is taken from other clients. This client only provides information to others. 
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is_memory_over_approximated: Returns true when the exploration frontier is 
empty and no state was force-terminated due to a failure. A majority of failures 
come from an SMT solver, which fails to decide satisfiability of a path condition 
of a program state. Another important sources are unsupported bit operators 
and presence of inline assembly. 

can_improve_memory_over_approximatioii: Returns true if the exploration 

frontier is not empty. Otherwise, returns false. 

on_location_outdated; This function does nothing, since this client does not 
take any information from others. The client only provides information. 


Correctness 

The client does not accept values from others. 


3.3 Server: The tool 


The server implements all his protocol functions (see section 2.4) in purely se¬ 
quential manner. It means that clients are queried for responses one by one 
and when all responses are collected the result is returned back the the client 
initiating the query. 

The server and all clients run of the same main thread and all queries from 
clients are issued also from that thread. It means that all queries are issued 
sequentially: A next query may be issues only after the previous one is completed. 


3.4 Evaluation 

We evaluated clients of the case study in five different configurations. Each con¬ 
figuration specifies what clients are used and whether they can communicate or 
not. We denote configurations using the following abbreviations: b*p*s, b-bp-bs, 
b-bp, b-bs, p-bs. Symbols ‘b’, ‘p’, and ‘s’ stand for Box, Polka, and Symbolic 
execution respectively, and ‘-b’ and stand for communication enabled and 
disabled respectively. For each configuration we assume that either all clients 
communicate with each other (the use of ‘-b’) or none of them (the use of 

We performed the evaluation on SV-COMP 2015 [55] benchmark suite, re¬ 
vision 571. The revision consists of 5861 benchmarks in 48 directories. In order 
to make the evaluation manageable for us, we put a requirement that whole the 
evaluation should finish within one week of continuous computatiorj^ Therefore, 
we picked 10 randomly chosen benchmarks from each directory (or less if there 
was not enough) and so we got 473 benchmarks in 48 directories, see Appendix[C| 
Since this was still not enough we set a time-out 2.5 minutes and a memory-out 
512MB for each client in each configuration. It means, for example, that b-bp 

^ The used a server: 32xlntel Xenon E5-2650 @ 2GHz, 64GB RAM, Debian 4.6.3. 
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had the time-out 5 minutes and the memory-out 1024MB, b*p*s had the time¬ 
out 7.5 minutes and the memory-out 1536MB, etc. Remember that clients share 
time (steps are interleaved) and memory (all run on a single thread) within a 
configuration, see pageflB} 

We compared results of each combination of configurations. The compari¬ 
son was always done separately per client: given two configurations and a client 
appearing in both of them we only consider results of that client in both config¬ 
urations for the comparison. 


Configuration 
1st 2nd 

Comparison per node 
fail neq eq 1st 2nd 

Comparison per benchmark 
fail neq 1st 2nd 1st! 2nd! eq! 

b*p*s 

b-bp-bs 

13 

246 

13021 627 

9563 

1 

20 

56 

191 

23 

148 

35 

b*p*s 

b-bp 

13 

342 

15042 613 

10043 

1 

37 

46 

243 

7 

186 

34 

b*p*s 

b-bs 

13 

309 

12444 450 

8202 

1 

10 

36 

128 

28 

115 

71 

b-l-p-l-s 

b-bp 

13 

1167 25025 3707 

1851 

1 

42 

120 123 

43 

48 

97 

b-l-p-l-s 

b-bs 

13 

142 

24753 1170 

708 

1 

14 

66 

34 

43 

17 

155 

b-bp 

b-bs 

13 

889 

21311 1798 

2899 

1 

41 

106 

76 

56 

28 

99 


Configuration 
1st 2nd 

Comparison per node 
fail neq eq 1st 2nd 

Comparison per benchmark 
fail neq 1st 2nd 1st! 2nd! eq! 

b*p*s 

b-bp-bs 

20 

487 10616 401 

12672 

1 

42 

38 

199 

16 

157 

43 

b*p*s 

b-bp 

26 

319 11691 168 

12923 

1 

39 

23 

224 

5 

183 

51 

b*p*s 

p-bs 

20 

609 10689 455 

12119 

1 

57 

44 

196 

12 

136 

50 

b-bp-bs 

b-bp 

14 

663 30462 2217 

1489 

1 

29 

93 

87 

50 
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Fig. 4. Comparison of invariants for clients Box (top) and Polka (bottom). Meaning of 
columns from left: ‘Tst”,“2nd” - 1st and 2nd compared configuration, “fail” - failures 
of Z3, “neq” - incomparable (neither is stronger), “eq” - logically equal, “lst”,“2nd” - 
1st,2nd configuration has stronger invariant ; “fail” - at least one Z3 failure, “neq” - 
contains incomparable invariants, “1st”,“2nd” - has at least one stronger invariant than 
in 2nd,1st configuration, “Ist!”, “2nd!” - at least one stronger but no weaker invariant 
than in 2st,lnd configuration, “eq!” - all invariant are logically equal. 


We focused on two kinds of measurements. First, we compared a precision 
of invariants computed by clients Box and Polka. Symbolic execution does not 
provide this kind of information. The clients attempt to compute for each node 
a strongest invariant over-approximating all concrete states which can be seen 
at the node. We used Z3 m SMT solver to compare invariants. Results are pre¬ 
sented in Fig. The numbers for “Comparison per node” are summary counts 
of nodes of all considered benchmarks together. And the numbers for “Compar¬ 
ison per benchmark” are simply counts of considered benchmarks. Note that for 
each client there were only considered those benchmarks for which the client 
terminated with the state “Success” in both compared configurations. 
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We can observe the following facts in data in Fig. 

— Each configuration may bring us improvements over others: We can clearly 
see this phenomena for all pairs of configurations in both kinds of com¬ 
parisons in tables of both clients. We can thus expect that for any chosen 
combination of clients we get some new results in terms of strengthened 
invariants. 

— There is no configuration strictly dominating all others: We can only read 
patterns in the data, like: 

• A configurations with communicating clients gives us at least one order 
of magnitude more precise invariants than isolated clients. 

• More communicating clients, more strengthened invariants. 

• Count of incomparable invariants and lower count of strengthened in¬ 
variants can be expected in the same order of magnitude. 

• More improved invariants typically yields more improved benchmarks, 
i.e. improvements are rather regularly distributed than highly concen¬ 
trated in few benchmarks. Nevertheless, a degree of correlation is sensi¬ 
tive to kinds of clients appearing in configurations, cf. fourth and sixth 
rows for both Box and Polka. 

Observations made for invariants can easily be adopted to very similar ob¬ 
servations for benchmarks. 

In the second measurement we focused on comparison of termination states 
of individual clients as they are used in different configurations. We distinguish 
termination states “Success”, “Time-out”, “Memory-out”, and “Crash”, all with 
obvious meanings. Results are presented in Fig. Numbers in each table repre¬ 
sent counts of benchmarks. 

We can observe the following facts in data in Fig. 

— Consumption of resources via communication does not imply a decrease of 
successful termination: Considering “Success” data for all configurations 
comparing with b*p*s for all clients, the communication caused a lose of 
success termination states in the following percentages: 


1st 

2nd 

Box Polka Sym.exec. 

b*p*s 

b-fp-bs 

3.8 -3.2 

1.9 

b*p*s 

b-bp 

-8.4 -9.5 

- 

b*p*s 

b-bs 

11.5 - 

-0.6 

b*p*s 

p-bs 

- -3.5 

3.2 


In 5 of 9 cases we see an increase of “Success” termination states. The average 
of these numbers is -0.53%. We may thus expect about 0.5% increase of 
“Success” termination states on average per client due to reduced overall 
time and memory consumption (the influence of crashes is less than 6%). 

— Resources consumption via communication heavily depends on kinds of clients: 
This statement is based on the following patterns which dominate data: 

• Symbolic execution is a major source of “Time-out” termination states. 
We can see this is tables of all clients: Whenever the client is present, 
there is a high count of time-outs. 
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Fig. 5. Comparison of termination states for clients Box (top), Polka (middle), and 
Symbolic execution (bottom). Columns of “Configuration”: “1st”,“2nd” - 1st and 2nd 
compared configuration ; All other columns: “eq” - equal state, “1st”,“2nd” - 1st,2nd 
configuration has the state while 2nd, 1st has some other. 


• Polka is a major source of “Memory-out” termination states. We can see 
this is tables of all clients: Whenever the client is present, there is a high 
count of memory-outs. 

The facts we observed in data of both figures lead as to a conclusion: 

In order to get the best result we should run as many configurations as possible 
and then merge their results. Sinee resources are always limited (like a number 
of available computers or threads), we should use patterns (similar to those we 
observed) in order to express preferences for certain configurations. 

It is important to add that the presented anonymous communication ap¬ 
proach provides a cheap way for building combinations of clients. Indeed, a 
construction of a new client mostly involves an implementation of the commu¬ 
nication interface and choosing right locations in client’s code, where to issue 
communication queries. Now, having the best result for a certain benchmark for 
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a group of n clients, an addition of a single new one will automatically gives as 
1 + X]fe=i configurations each with a potential to improve the 

old result. In the case of our evaluation we would immediately get eight new 
such configurations ready for execution. 

An interested reader may have a look to Appendix where we put the 
presented data in a form of histograms. A package with sources and binaries 
of the tool used in the evaluation together with the computed results is freely 
available here (53]. Details about the download, installation, and the use can be 
found in Appendix [B} 

4 Related Work 

There is a broad class of approaches dedicated to combining of lattice-based 
analyses. They all are based either on a direct or a reduced product [5]. 

A direct product is fully automatic, it requires neither writing of resulting 
operations nor modifications of the input ones. Nevertheless, composed analyses 
do not interact and the product represents the least precise Cartesian product 
of the analyses. No check for correctness is required. 

A reduced product is in contrary the most precise Cartesian product, but it 
is based on (non-computable) concretisation functions used in so called “reduce” 
function. In practice, the issue is typically resolved by providing an approxima¬ 
tion of the reduce function. But this implies a dedicated implementation for each 
given combination of analyses. It is also necessary to check for correctness of the 
approximation. 

A logical product m automatically construct the most precise reduced prod¬ 
uct of analyses whose elements are conjunctions of atomic facts over theories that 
are convex, stably infinite, and disjoint. No check for correctness is required. 

In [5D] authors combine abstract domains for shape analyses using reduced 
product. Each component reasons independently about different aspects of the 
data structure invariant and then separately exchange information via a reduc¬ 
tion operator. 

Granger’s product m provides an elegant approximation of the reduce func¬ 
tion of a reduced product. Each input analysis is extended by its own reduce 
function from domains of all analyses to domain of the analysis owning the 
function. Each analysis must only check whether its reduce function satisfies 
necessary requirements. Note that each combination of analysis requires new 
dedicated implementations of reduce functions. 

An open product [5] substantially improves the Granger’s product, since it 
removes the dependence between analyses. The only common property is an a 
priory given set of queries (e.g. in the logic paradigm: “is a variable x surely 
bound to a ground term?”). Each operation of each analysis is extended s.t. it 
is parametrised by all possible valuations of the queries. Analyses are thus also 
extended by boolean functions capable to compute individual parametrisations. 
Each analysis has to check for itself for correctness of its extension. 
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The requirement of a set of predefined queries in an open product was later 
relaxed in [3] by replacing them by a language of the first order logic. Operations 
of all analyses can then be parametrised by any formula of the language. 

Composition of configurable program analyses [T] is based on a direct prod¬ 
uct, whose precision can be improved via relations “transfer”, “merge”, “stop”, 
“compare”, and “strengthen”. Each of these relations is defined over domains of 
all composed analyses. Implementations of relations transfer, merge, and stop 
cannot access abstract states of individual analyses, they can only apply their 
operators and relations. There is no such restriction for implementations of com¬ 
pare and strengthen. These two relations can be used in implementations of the 
previous three. The composition requires neither modification nor extension of 
implementations of input analyses. Nevertheless, the five relations mentioned 
above require dedicated implementations for each combination of analyses. An 
improved concept by a dynamic precision adjustment [2] introduced a relation 
“prec”. This relation is also defined over domains of all composed analyses, so 
its implementations also has to be provided for each combination of analyses. 
In both the original and the improved concept one needs to check whether his 
implementations of all the relations satisfy necessary requirements. It is further 
important to mention that in [T] there was introduced a “location analysis” 
modeling instruction counter. It can be composed with other analyses. 

An advanced combination of lattice-based analyses can be found in Astree [9] . 
It is based on the idea of an open product with several extensions. The set of fixed 
queries was replaced by an extensible set of kinds of constraints. An extension of 
the set be a new kind implies extensions and checks for correctness of only those 
analyses which want to use constraints of that kind. A constraint represents an 
information of its kind about an analysed program. Analyses may exchange infor¬ 
mation through input and output channels. Input channels provide information 
on both the postcondition being computed and the precondition computed in 
the last computation step. Output channels are used when an analysis wants to 
send a message to others. Messages are elements of a separate abstract domain. 
Messages are not always exchanged freely between analyses. An order of analyses 
in a computational step matters. Typically, an analysis may freely communicate 
with any predecessor. 

An obvious difference between our approach and approaches above is that our 
approach is not restricted to lattice-based analyses. Further important differences 
can be expressed in terms of three features we mentioned in the introduction: 


— Independence of clients: This feature provide only approaches based on the 
open product, i.e. |5I3I9] . 

— Asynchronous execution of clients: Approaches above do not natively provide 
this feature. Computational steps of all analyses are synchronised, i.e. they all 
run in the same speed. An asynchronous execution can be emulated in some 
extent in [T] through the use of several location analyses in one combination: 
some location analysis stays on a certain location in several subsequents 
steps in order to simulate slow-down of dependent analyses. Nevertheless, 
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by a use of more than one location analysis in a combination we may expect 
enormous increase of complexity in designing relations transfer, merge, etc. 

— Reuse of current implementations: Approaches based on the open product 
are suited for the reuse. Nevertheless, approaches [SEE] require that all 
composed analyses (synchronously) run on the same internal program rep¬ 
resentation. And in [Tj the reuse requires to look inside implementation of 
each analysis and discover how the program is internally represented. Then 
corresponding location analyses can be designed and implemented together 
with all relations transfer, merge, etc. Nevertheless, this may imply enor¬ 
mous amount of programing effort (which has to be repeated for different 
combinations of analyses). 

There is another broad class of approaches devoted to combining of program 
analyses. They are focused on combining specific kinds of analyses. Typically, 
two or more particular analyses are considered, e.g. predicate abstraction with 
dynamic test generation [T^] , static checking and testing finiTiTi , different testing 
techniques [5], symbolic and concrete execution m, static and dynamic analy¬ 
ses via program partitioning data-flow with predicate lattices m , data-flow 
analyses in a compiler lllITj, etc., and a result is a new program analysis pos¬ 
sessing advantages of individual analyses. Although these approaches give us 
interesting new algorithms and ideas, they are orthogonal to our approach: Our 
approach does not build “a new analysis”, we proposed an analysis-independent 
communication model. In other words, we took an alternative path. 

5 Conclusion 

We presented an approach for a light-weight anonymous online communication 
of existing implementations of program analyses (i.e. clients). In order to com¬ 
municate with others a client has to implements the proposed client’s commu¬ 
nication protocol and to identify places in his implementation where to issue 
queries s.t. the received information may subsequently help to improve client’s 
results. These steps are completely independent on other clients. The client also 
has to check by himself for correctness of his analysis for all possible communica¬ 
tion scenarios which may occur during analysis of a given program. Each client 
performs his work on a private data and an internal program representation. 
Nevertheless, the communication is performed in terms of common model of in¬ 
struction counter (canonical program) and common memory addressing (canon¬ 
ical memory). Therefore, communication queries are are typically coupled with 
conversions from client’s internal data to common terms and back. 

We also presented a case study with three communicating clients: two ab¬ 
stract interpreters (intervals, polyhedrons) and one classic symbolic execution. 
We evaluated five their configurations (how many and what client will communi¬ 
cate) and we pairwise compared their results per client. We measured strength¬ 
ening of invariant (for abstract interpreters) and termination states (for all). 
The data shows that each combination may bring us new improvements in both 
strengthened invariants and increased count of “success” termination states. 
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Therefore, since there are 2" — 1 configurations for n clients, we can achieve 

substantial gain compared to results of n isolated clients. 
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A Plots 


Here we present data summarised in Fig. and Fig in a form of histograms. 
They are automatically produced by the tool after evaluation (and then prettify 
by our utility ’STATOR-tool/plotcopy .py’). Data in the mentioned figures were 
collected from the histograms. 
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Fig. 6. Comparison: b+p+s vs. b+p. 
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Fig. 7. Comparison: b+p+s vs. b+s. 
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Fig. 9. Comparison: b+p vs. b+s. 
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Fig. 10. Comparison: b+p vs. p+s. 
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Fig. 11. Comparison: b+s vs. p+s. 
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Fig. 12. Comparison: b*p*s vs. b+p. 
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Fig. 14. Comparison: b*p*s vs. b+s. 
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Fig. 15. Comparison: b*p*s vs. p+s. 
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B Access to the tool and Evaluation 


The binary of the tool and all results of the evaluation are available here [?i] . 
The binary can be run Linux 64 bit operating system. The tool was tested on 
Linux Mint 17 and Debian 4.6.3. The binary also runs on Ubuntu 14.04. 

Installation is very simple. Download the ZIP package, unzip it into some di¬ 
rectory, and the tool is ready for an execution. The tool is located in STATOR-tool 
sub-directory, the result from our evaluation in SVCOMP-repo.ORIG.EVAL sub¬ 
directory. Note that SV-COMP benchmarks are not included in the package. 
They have to be downloaded separately. All necessary info about this can be 
found in Appendix [C| 

Use Python script STATOR-tool/start .py to run the tool on a single C file 
you have to execute . Use the option — help to list detailed info of usage. In order 
to run the evaluation for several benchmarks you have to execute Python script 
STATOR-tool/start_evaluation.py. Use the option — help to list detailed info 
of usage. In all cases input C file(s) have to always be preprocessed. 

In case you want to recompute results of our evaluation we prepared a ded¬ 
icated shell script STAT0R_SVC0MP_evaluate. sh located in the root directory 
which calls STATOR-tool/start_evaluation.py with our settings. Note the 
shell script assumes that SV-COMP repository was cloned into sub-directory 
SVCOMP-repo (which is empty in our package). 


C List of Benchmarks 

Here we list all benchmarks we used in evaluations. The list references to SV- 
COMP 2015 [20] benchmark suite, revision 571. 

Summary info: 

— URL: https://svn.sosy-lab.org/software/sv-benchmarks/tags/svcompl5 

— revision: 571 

— Number of current benchmarks: 473 

— Number of current directories: 48 

• array-examples [10 benchmarks] 

• bitvector [10 benchmarks] 

• * bitvector-regression [9 benchmarks] 

• ddv-machzwd [10 benchmarks] 

• eca-rers2012 [10 benchmarks] 

• float-benchs [10 benchmarks] 

• floats-cbmc-regression [10 benchmarks] 

• floats-cdfpl [10 benchmarks] 

• * heap-manipulation [8 benchmarks] 

• Idv-commit-tester [10 benchmarks] 

• Idv-consumption [10 benchmarks] 

• ldv-linux-3.0 [10 benchmarks] 

• ldv-linux-3.12-rcl [10 benchmarks] 

• ldv-linux-3.16-rcl [10 benchmarks] 
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• ldv-linux-3.4-simple [10 benchmarks] 

• ldv-linux-3.7.3 [10 benchmarks] 

• Idv-regression [10 benchmarks] 

• IdV-validator-vO.6 [10 benchmarks] 

• list-ext-properties [10 benchmarks] 

• list-properties [10 benchmarks] 

• locks [10 benchmarks] 

• loop-acceleration [10 benchmarks] 

• loop-invgen [10 benchmarks] 

• loop-lit [10 benchmarks] 

• * loop-new [8 benchmarks] 

• loops [10 benchmarks] 

• memory-alloca [10 benchmarks] 

• memsafety [10 benchmarks] 

• * memsafety-ext [8 benchmarks] 

• ntdrivers [10 benchmarks] 

• ntdrivers-simplihed [10 benchmarks] 

• product-lines [10 benchmarks] 

• pthread [10 benchmarks] 

• pthread-atomic [10 benchmarks] 

• pthread-ext [10 benchmarks] 

• pthread-lit [10 benchmarks] 

• pthread-wmm [10 benchmarks] 

• recursive [10 benchmarks] 

• recursive-simple [10 benchmarks] 

• seq-mthreaded [10 benchmarks] 

• seq-pthread [10 benchmarks] 

• ssh [10 benchmarks] 

• ssh-simplified [10 benchmarks] 

• systemc [10 benchmarks] 

• termination-crafted [10 benchmarks] 

• termination-crafted-lit [10 benchmarks] 

• termination-memory-alloca [10 benchmarks] 

• termination-numeric [10 benchmarks] 

List of benchmarks: 


— ./array-examples/data_structures_set_multi_proc_false-unreach-calLground.i 

— ./array-examples/data_structures_set_multi_proc_true-unreach-calLground.i 

— ./array-examples/sanfoundry_24_true-unreach-call.i 

— ./array-examples/sorting_bubblesort_false-unreach-calLground.i 

— ./array-examples/standard_compare_true-unreach-call_ground.i 

— ./array-examples/standard_copy2_true-unreach-calLground.i 

— ./array-examples/standard_init3_true-unreach-calLground.i 

— ./array-examples/standard_partition_false-unreach-calLground.i 

— ./array-examples/standard_two_index_08_true-unreach-call.i 

— ./array-examples/standard_vector_difference_true-unreach-calLground.i 
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./bitvector-regression/implicitfloatconversion_false-unreach-call.i 

./bitvector-regression/implicitunsigneclconversion_false-unreach-call.i 

./bitvector-regression/implicitunsignedconversion.true-unreach-call.i 

./bitvector-regression/integerpromotion_false-unreach-call.i 

./bitvector-regression/integerpromotion_true-unreach-call.i 

. /bitvector-regression/signextension2_false-unreach-call.i 

./bitvector-regression/signextension2_true-unreach-call.i 

./bitvector-regression/signextension_false-unreach-call.i 

./bitvector-regression/signextension_true-unreach-call.i 

./bitvector/byte_add_false-unreach-call.i 

./bitvector/gcd_4_true-unreach-call.i 

./bitvector/interleave_bits_true-unreach-call.i 

. /bit vector/j ain_7_true-unreach-call. i 

./bitvector/modulus_true-unreach-call.i 

. /bitvector/num_conversion_l _true-unreach-call.i 

./bitvector/parity_true-unreach-call.i 

./bitvector/s3_clnt_l_false-unreach-call.BV.c.cil.c 

./bitvector/soft _float_5_true-unreach-call.c.cil.c 

./bitvector/sum02_true-unreach-call.i 

. /ddv-machzwd / ddv _machzwd_all_false-unreach-call, i 

. /ddv-machzwd / ddv _machzwd_inb_p_true-unreach-call, i 

. /ddv-machzwd / ddv _machzwd_inb_true-unreach-call, i 

./ddv-machzwd/ddv_machzwd_inLp_true-unreach-call.i 

./ddv-machzwd/ddv_machzwd_inl_true-unreach-call.i 

./ddv-machzwd/ddv_machzwd_inw_p_true-unreach-call.i 

. /ddv-machzwd / ddv_machzwd_outb_false-unreach-call.i 

./ddv-machzwd/ddv_machzwd_outb_p_true-unreach-call.i 

./ddv-machzwd/ddv_machzwd_outLtrue-unreach-call.i 

. /ddv-machzwd / ddv _machzwd_outw_p_true-unreach-call, i 

. /eca-rers2012/ProblemO 1 JabelO 1 _true-unreach-call. c 

./eca-rers2012/Problem01 Jabel03_true-unreach-call.c 

./eca-rers2012/Problem01_labell0_true-unreach-call.c 

./eca-rers2012/Problem05_label48_false-unreach-call.c 

./eca-rers2012/Probleml0Jabel57_false-unreach-call.c 

./eca-rers2012/Probleml0_label58_false-unreach-call.c 

./eca-rers2012/Problemll_labell5_false-unreach-call.c 

./eca-rers2012/Problemll_labell8_true-unreach-call.c 

./eca-rers2012/Probleml9Jabel52_true-unreach-call.c 

./eca-rers2012/Probleml9_label59_false-unreach-call.c 

./float-benchs/float_int_inv_square_false-unreach-call.c 

./float-benchs/inv_square_int_true-unreach-call.c 

./float-benchs/inv_square_true-unreach-call.c 

./float-benchs/nan_double_false-unreach-call.c 

./float-benchs/nan_double_union_true-unreach-call.c 

./float-benchs/nan_float_mask_true-unreach-call.c 

./float-benchs/nan_float_range_true-unreach-call.c 
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./float-benchs/nan_float_union_true-unreach-call.c 
./float-benchs/sinJnterpolatedJndex_false-unreach-call.c 
./float-benchs/sin_interpolated_smallrange_true-unreach-call.c 
./floats-cbmc-regression/lloat-flags-simpl_true-unreach-call.i 
./floats-cbmc-regression/lloat-no-simpl_true-unreach-call.i 
./floats-cbmc-regression/lloat-no-simp2_true-unreach-call.i 
./floats-cbmc-regression/lloat-zero-suml_true-unreach-call.i 
. /floats-cbmc-regression/lloat 1 l_true-unreach-call.i 
. /floats-cbmc-regression/lloat 14_true-unreach-call.i 
./floats-cbmc-regression/float22_true-unreach-call.i 
./floats-cbmc-regression/float3_true-unreach-call.i 
./floats-cbmc-regression/float6_true-unreach-call.i 
./floats-cbmc-regression/float8_true-unreach-call.i 
./floats-cdfpl/newton_l_4_false-unreach-call.i 
. /floats-cdfpl / newton_2_l _true-unreach-call.i 
./floats-cdfpl/newton_2_7_false-unreach-call.i 
./floats-cdfpl/newton_3_8_false-unreach-call.i 
./floats-cdfpl/sine_3-false-unreach-call.i 
./floats-cdfpl/sine_4_true-unreach-call.i 
./floats-cdfpl/sine_8_true-unreach-call.i 
. /floats-cdfpl / square_l _false-unreach-call.i 
./floats-cdfpl/square_7_true-unreach-call.i 
./floats-cdfpl/square_8_true-unreach-call.i 
./heap-manipulation/bubble_sort_linux-false-unreach-call.i 
./heap-manipulation/bubble_sort_linux_true-unreach-call.i 
./heap-manipulation/dlLoLdlLfalse-unreach-call.i 
./heap-manipulation/dlLoLdlLtrue-unreach-call.i 
. /heap-manipulation / merge _sort .false-unreach-call, i 
./heap-manipulation/merge_sort_true-unreach-call.i 
./heap-manipulation/slLto_dlLrev-false-unreach-call.i 
./heap-manipulation/sll-tO-dlLrev-true-unreach-call.i 

./Idv-commit-tester/m0_false-unreach-call_drivers-media-radio-si4713-i2c-ko- 

-lll-la-064368f-l.c 

./Idv-commit-tester/m0_true-unreach-call_drivers-hwmon-s3c-hwmon-ko—130-7a- 
-af3071a.c 

. /Idv-commit-tester / mO_true-unreach-call_drivers-media-video-cx88-cx88-blackbird- 
ko-32-7a-d47b389.c 

. /Idv-commit-tester / mO_true-unreach-call_drivers-media-video-cx88-cx88-dvb- 
ko-32-7a-d47b389-l.c 

./Idv-commit-tester/mO _true-unreach-call_drivers-media-video-cx88-cx8802-ko- 
-32-7a-d47b389.c 

. /Idv-commit-tester / mO_true-unreach-calLdrivers-net-forcedeth-ko— 114-la— 
fea891e-l.c 

. /Idv-commit-tester / main2-true-unreach-call-drivers-media-video-tlg2300-poseidon- 
ko—32-7a—4a349aa.c 
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./ldv-commit-tester/main3_true-unreach-calLarch-x86-oprofile-oprofile-ko—131_la- 
-79db8ef.c 

./ldv-commit-tester/main4_true-unreach-calLarch-x86-oprofile-oprofile-ko—131_la- 
-79db8ef-l.c 

./ldv-commit-tester/main7_true-unreach-calLsound-oss-sound-ko—32_7a--c4cbldd- 
l.c 

./ldv-consumption/32_7a_cilled_false-unreach-calLlinux-3.8-rcl-32_7a-drivers- 
-ata—libata.ko-ldv_main4_sequenceJnfinite_withcheck_stateful.cil.out.c 
./ldv-consumption/32_7a_cilled_false-unreach-calLlinux-3.8-rcl-32_7a-fs--ceph- 
-ceph.ko-ldv_mainll_sequence_infinite_withcheck_stateful.cil.out.c 
./ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rcl-32_7a-drivers- 
-block—paride—pf.ko-ldv_mainO_sequence_infinite_withcheck_stateful.cil.out.c 
./ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rcl-32_7a-drivers- 
-block—paride—pt.ko-ldv_mainO _sequence_infinite_withcheck_stateful.cil.out.c 
./ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rcl-32_7a-drivers- 
-usb—host—xhci-hcd.ko-ldv _main5_sequence_infinite_withcheck_stateful.cil.out.c 
./ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rcl-32_7a-fs—nfs- 
-nfsv4.ko-ldv_main4_sequence_infinite_withcheck_stateful.cil.out.c 
./ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rcl-drivers—block- 
-paride—pt.ko-main.cil.out.c 

./ldv-consumption/32_7a_cilled_true-unreach-call_linux-3.8-rcl-drivers—vfio— 
pci—vfio-pci. ko- main. cil. out. c 

./ldv-consumption/linux-3.8-rcl-32_7a-drivers—media—usb—em28xx—em28xx.ko- 
ldv_mainO _true-unreach-call. cil. out .c 

./ldv-consumption/linux-3.8-rcl-32_7a-drivers—usb—core—usbcore.ko-ldv_mainl3_false- 
unreach-call . cil. out .c 

./ldv-linux-3.0/module_get_put-drivers-atm-eni.ko_true-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.0/module_get_put-drivers-block-drbd-drbd.ko_true-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.0/module_get_put-drivers-net-ppp_generic.ko_false-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.0/module_get_put-drivers-net-wan-farsync.ko_false-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.0/usb_urb-drivers-input-misc-keyspan_remote.ko-false-unreach- 
call.cil.out.i.pp.i 

./ldv-linux-3.0/usb_urb-drivers-input-tablet-kbtab.ko_true-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.0/usb_urb-drivers-media-dvb-ttusb-dec-ttusb_dec.ko_false-unreach- 
call.cil.out.i.pp.i 

./ldv-linux-3.0/usb_urb-drivers-media-video-c-qcam.ko_true-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.0/usb_urb-drivers-net-usb-catc.ko_false-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.0/usb_urb-drivers-vhost-vhost_net.ko_true-unreach-call.cil.out.i.pp.i 
./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—input—misc—ims-pcu.ko- 
entry_point_false-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—isdn—hisax—hisax_st5481.ko- 
entry _point_false-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—media—rc—imon.ko- 
entry_point_false-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—media—usb—stkll60- 

-stkll60.ko-entry_point_false-unreach-call.cil.out.c 
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./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—media—usb--usbvision- 

-usbvision.ko-entry_poiiit_false-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—net--can—usb--esd_usb2.ko- 

entry_point_true-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—net--usb--cdc_mbim.ko- 

entry_point_true-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—net--usb--smsc95xx.ko- 
entry _point_false-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—staging—gdm72xx— 
gdmwm.ko-entry_point_false-unreach-call.cil.out.c 

./ldv-linux-3.12-rcl/linux-3.12-rcl.tar.xz-144_2a-drivers—usb—misc—idmouse.ko- 
entry _point_false-unreach-call.cil.out.c 

./ldv-linux-3.16-rcl/205_9a_array_unsafes_linux-3.16-rcl.tar.xz-205_9a-drivers- 
-net—wan—lapbether.ko-entry_point_false-unreach-call.cil.out.c 
./ldv-linux-3.16-rcl/205_9a_array_unsafesJinux-3.16-rcl.tar.xz-205_9a-drivers- 
-net—wireless—ath—ath6kl—ath6kLusb.ko-entry_point_false-unreach-call.cil.out.c 
./ldv-linux-3.16-rcl/205_9a_array_unsafes_linux-3.16-rcl.tar.xz-205_9a-drivers- 
-net—wireless—ath—wcn36xx—wcn36xx.ko-entry _point_false-unreach-call.cil.out.c 
./ldv-linux-3.16-rcl/205_9a_array_unsafesdinux-3.16-rcl.tar.xz-205_9a-drivers- 
-net—wireless—hostap—hostap-plx.ko-entry _point_false-unreach-call.cil.out.c 
./ldv-linux-3.16-rcl/43_2a_consumption_linux-3.16-rcl.tar.xz-43_2a-drivers—input- 
-gameport—ns558.ko-entry_point_true-unreach-call.cil.out.c 

./ldv-linux-3.16-rcl/43_2a_consumptiondinux-3.16-rcl.tar.xz-43_2a-drivers—target- 
-sbp—sbp_target.ko-entry _point_true-unreach-call.cil.out.c 
./ldv-linux-3.16-rcl/43_2a_consumption_linux-3.16-rcl.tar.xz-43_2a-drivers—tty- 
-isicom.ko-entry_point_true-unreach-call.cil.out.c 

./ldv-linux-3.16-rcl/43_2a_consumptiondinux-3.16-rcl.tar.xz-43_2a-drivers—tty- 
-serial—8250—8250.ko-entry_point_true-unreach-call.cil.out.c 
./ldv-linux-3.16-rcl/43_2a_consumption_linux-3.16-rcl.tar.xz-43_2a-drivers—tty- 
-serial—8250—8250_pci.ko-entry_point_true-unreach-call.cil.out.c 
./ldv-linux-3.16-rcl/43_2a_consumption_linux-3.16-rcl.tar.xz-43_2a-drivers—video- 
-fbdev—via—viafb.ko-entry _point_true-unreach-call.cil.out.c 
./ldv-linux-3.4-simple/32_l_cilled_true-unreach-calLok_nondet_linux-3.4-32_l- 
drivers—acpi—bgrt.ko-ldv_main0-Sequence _infinite_withcheck_stateful.cil.out.c 
./ldv-linux-3.4-simple/32_l_cilled_true-unreach-calLok_nondet_linux-3.4-32_l- 

drivers—media—dvb-dvb-usb—dvb-usb-dibusb-mc.ko-ldv_mainO_sequence_infinite_withcheck_stateful.cil.ou 
./ldv-linux-3.4-simple/32_l_cilled_true-unreach-calLok_nondet_linux-3.4-32_l- 

drivers—media—dvb-dvb-usb—dvb-usb-digitv.ko-ldv_mainO_sequence_infinite_withcheck_stateful.cil.out.c 

./ldv-linux-3.4-simple/43_la_cilled_true-unreach-calLok_nondet_linux-43_la-drivers- 

-media—dvb-dvb-usb—dvb-usb-vp702x.ko-ldv_mainl_sequence_infinite_withcheck_stateful.cil.out.c 

./ldv-linux-3.4-simple/43_la_cilled_true-unreach-calLok_nondetJinux-43_la-drivers- 

-media—dvb—frontends—dib3000mc.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c 

./ldv-linux-3.4-simple/43_la_cilled_true-unreach-calLok_nondet_linux-43_la-drivers- 

-media—video—gspca—gspca_jl2005bcd.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c 

./ldv-linux-3.4-simple/43_la_cilled_true-unreach-calLok_nondetJinux-43_la-drivers- 

-media—video—gspca—gspca_pac207.ko-ldv_main0_sequence_infinite_withcheck_stateful.cil.out.c 
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./ldv-linux-3.4-siinple/43_la_cilled_true-unreach-calLok_nondet_linux-43_la-drivers- 
-media--video—gspca—gspca_stv0680.ko-ldv_main0_sequence_infiiiite_withcheck_stateful.cil.out.c 
./ldv-linux-3.4-simple/43_la_cilled_true-unreach-calLok_nondet_linux-43_la-drivers- 
-watchdog—wdt_pci.ko-ldv_mainO_sequence_infinite_withcheck_stateful.cil.out.c 
./ldv-linux-3.4-simple/43_la_cilled_true-unreach-calLok_nondet_linux-43_la-drivers- 
-xen—xenfs—xenfs.ko-ldv_mainO_sequence_infinite_withcheck_stateful.cil.out.c 
./ldv-linux-3.7.3/linux-3.10-rcl-43_la-bitvector-drivers—atm—he.ko-ldv.mainO-true- 
unreach-call. cil . out .c 

. /ldv-linux-3.7.3/mainO_false-unreach-calLdrivers—media—dvb-frontends—stvOQOx- 
ko-“3 2 _7 a— linux- 3.7.3. c 

./ldv-linux-3.7.3/mainO _false-unreach-calLdrivers-net-wireless-mwl8k-ko—32_7a- 
-linux-3.7.3.c 

./ldv-linux-3.7.3/mainl l_false-unreach-calLdrivers-usb-core-usbcore-ko—32_7a- 
-linux-3.7.3.c 

./ldv-linux-3.7.3/mainl5_false-unreach-calLdrivers-usb-core-usbcore-ko—32_7a- 
-linux-3.7.3.c 

./ldv-linux-3.7.3/mainl7_false-unreacli-call_drivers-gpu-drm-vmwgfx-vmwgfx- 
ko—32_7a—linux-3.5.c 

./ldv-linux-3.7.3/mainl_false-unreach-calLdrivers-usb-core-usbcore-ko—32_7a- 
-linux-3.7.3.c 

./ldv-linux-3.7.3/mainl_false-unreach-calLdrivers-vhost-vhost-net-ko—32_7a- 
-linux-3.7.3.c 

./ldv-linux-3.7.3/main3_false-unreach-calLdrivers-gpu-drm-vmwgfx-vmwgfx- 
ko—32_7a—linux-3.5.c 

./ldv-linux-3.7.3/main4_false-unreach-calLdrivers-scsi-mpt2sas-mpt2sas-ko— 

32_7a—linux-3.7.3.c 

./ldv-regression/alias_of_return_2.c_true-unreacli-calLl.i 
./ldv-regression/nested_structure_ptr_true-unreacli-call.i 
. / Idv- regression/nested .structure _t rue-unreach-call. i 
./ldv-regression/sizeofparameters_test.c_true-unreach-call.i 
./Idv-regression/statefuLcheck_false-unreach-call.i 
./Idv-regression/test .address.c.true-unreach-call.i 
./Idv-regression/test.cut.trace.c.true-unreach-call.i 
./Idv-regression/test.union.cast.c.true-unreach-call.i 
./Idv-regression/test.union.cast.c.true-unreach-call.l.i 
./Idv-regression/volatile.alias.c.true-unreach-call.i 

./ldv-validator-v0.6/linux-stable-1575714-l-150_la-drivers—net—wireless—b43- 
-b43. ko-entry .point _false-unreach-call. cil. out .c 

./Idv-validator-v0.6/linux-stable-lb0b0ac-l-108.1a-drivers—net—slip.ko-entry .point.false- 
unreach-call. cil. out .c 

./Idv-validator-v0.6/linux-stable-42f9f8d-l-lll_la-sound— OSS— opl3.ko-entry .point.false- 
unreach-call. cil. out .c 

./Idv-validator-v0.6/linux-stable-431e8d4-l-102.1a-drivers—net—r8169.ko-entry .point.false- 
unreach-call. cil. out .c 

./Idv-validator-v0.6/linux-stable-4a349aa-l-32_7a-drivers—media—video—tlg2300- 
-poseidon.ko-entry .point-false-unreach-call.cil.out.c 
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./Idv-validator-v0.6/linux-stable-4ed3cba-l-100_la-drivers—usb—serial--qcserial.ko- 
entry _point_false-unreach-call.cil.out.c 

./Idv-validator-v0.6/linux-stable-5934df9-l-lll_la-drivers—scsi—gdth.ko-entry_point_false- 
unreach-call. cil. out .c 

./Idv-validator-v0.6/linux-stable-90a4845-l-110_la-drivers—char—ipmi—ipmi_si.ko- 
entry _point_false-unreach-call.cil.out.c 

./Idv-validator-v0.6/linux-stable-c0cc359-104_la-drivers—usb—serial—qcserial.ko- 
entry _point_false-unreach-call.cil.out.c 

./Idv-validator-v0.6/linux-torvalds-645ef9e-32_7a-sound— OSS— sound.ko-entry_point Jalse- 
unreach-call. cil. out .c 

. /list-ext-properties/960521-1 _1 _false-valid-deref.i 
. /list-ext-properties/960521-1 _1 _true-valid-memsafety.i 
./list-ext-properties/list-ext_l_true-valid-memsafety.i 
./list-ext-properties/simple-ext_l_true-valid-memsafety.i 
./list-ext-properties/test-0019_l_true-valid-memsafety.i 
./list-ext-properties/test-0158_l_false-valid-free.i 
./list-ext-properties/test-0214_l_true-valid-memsafety.i 
./list-ext-properties/test-0232_l_false-valid-memtrack.i 
./list-ext-properties/test-0232_l_true-valid-memsafety.i 
./list-ext-properties/test-0504_l_true-valid-memsafety.i 
. /list-properties / alternating.list _true-unreach-call. i 
./list-properties/list Jalse-unreach-call.i 
. /list-properties/list _flag_false-unreach-call, i 
./list-properties/list _flag_true-unreach-call.i 
./list-properties/list _search_false-unreach-call.i 
./list-properties/list _search_true-unreach-call.i 
./list-properties/simple_built_from_end_true-unreach-call.i 
./list-properties/simple_false-unreach-call.i 
./list-properties/siniple_true-unreach-call.i 
./list-properties/splice Jalse-unreach-call.i 
./locks/test Jocks_10Jrue-unreach-call.c 
./locks/test Jocks-llJrue-unreach-callJalse-termination.c 
./locks/test Jocks_13Jrue-unreach-call.c 
./locks/test Jocks_14Jalse-unreach-call.c 
./locks/test Jocks_14Jrue-unreach-call.c 
./locks/test Jocks_15Jrue-unreach-calLfalse-terniination.c 
./locks/test Jocks_5Jrue-unreach-call Jalse-termination.c 
./locks/test JocksJJrue-unreach-call Jalse-termination.c 
./locks/test Jocks_8_true-unreach-call Jalse-termination.c 
./locks/test Jocks_9Jrue-unreach-call.c 
./loop-acceleration/array Jalse-unreach-call2.i 
./loop-acceleration/array Jalse-unreach-call4.i 
./loop-acceleration/diamondJalse-unreach-call2.i 
./loop-acceleration/diamondJrue-unreach-calll.i 
. /loop-acceleration/diamond Jrue-unreach-call2 .i 
./loop-acceleration/multivar Jrue-unreach-calll.i 
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. /loop-acceleration / nested_false-unreach-calll. i 

. /loop-acceleration / phases_false-unreach-call2 .i 

./loop-acceleration/simple_true-unreach-call4.i 

./loop-acceleration/underapprox_true-unreach-call2.i 

./loop-invgen/NetBSD_loop_false-unreach-call.i 

./loop-invgen/SpamAssassin-loop_false-unreach-call.i 

./loop-invgen/down_true-unreach-call.i 

./loop-invgen/fragtest_simple_true-unreach-call.i 

./loop-invgen/half_2_true-unreach-call.i 

./loop-invgen/heapsort_true-unreach-call.i 

./loop-invgen/id_build_true-unreach-call.i 

./loop-invgen/nested9_true-unreach-call.i 

./loop-invgen/seq_true-unreach-call.i 

./loop-invgen/string_concat-noarr_true-unreach-call.i 

./loop-lit/afnp2014_true-unreach-call.c.i 

./loop-lit/cggmp2005_true-unreach-call.c.i 

./loop-lit/cggmp2005b_true-unreach-call.c.i 

./loop-lit/css2003_true-unreach-call.c.i 

./loop-lit/ddlm2013_true-unreach-call.c.i 

./loop-lit/gj2007b-true-unreach-call.c.i 

./loop-lit/gsv2008_true-unreach-call.c.i 

./loop-lit/jm2006_true-unreach-call.c.i 

./loop-lit/jm2006_variant_true-unreach-call.c.i 

./loop-lit/mcmillan2006_true-unreach-call.c.i 

./loop-new/count_by_l_true-unreach-call.i 

. /loop-new/count _by _1 .variant _true-unreach-call. i 

./loop-new/count_by_2-true-unreach-call.i 

./loop-new/count_by-k-true-unreach-call.i 

./loop-new/count_by_nondet_true-unreach-call.i 

./loop-new/gauss-sum-true-unreach-call, i 

./loop- new / half_t rue- unreach-call. i 

./loop-new/nested_true-unreach-call.i 

. /loops/array-false-unreach-call. i 

./loops/insertion_sort_true-unreach-call.i 

./loops/nec20_false-unreach-call.i 

./loops/sum01_bug02_sum01_bug02_base.case_false-unreach-calLtrue-termination.i 
./loops/terminator _02_false-unreach-calLtrue-termination.i 
./loops/terminator _03_true-unreach-calLtrue-termination.i 
./loops/trex03_false-unreach-call_true-termination.i 
./loops/veris.c_OpenSER__casesl_stripFullBoth_arr_true-unreach-call.i 
. /loops / vogaLfalse-unreach-call.i 

./loops/while_infinite_loop_2_true-unreach-calLfalse-termination.i 
./memory-alloca/HarrisLalNoriRajamani-2010SAS-Fig3-alloca_true-valid-memsafety.i 
./memory-alloca/array02-alloca_true-valid-memsafety.i 
./memory-alloca/cstrcmp-alloca_true-valid-memsafety.i 
./memory-alloca/cstrcpy-alloca_true-valid-memsafety.i 
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./meinory-alloca/cstrcpy_unsafe_false-valid-deref.i 
./ineinory-alloca/cstrlen_unsafe_false-valid-deref.i 
./inemory-alloca/openbsd_cstrcpy-alloca_true-valid-inemsafety.i 
./ineinory-alloca/reverse_array_alloca_unsafe_false-valid-deref.i 
./inemory-alloca/reverse_array_unsafe_false-valid-deref.i 
./meinory-alloca/selection_sort_unsafe_false-valid-deref.i 
./memsafety-ext / dlLextends_pointer_true-valid-memsafety.i 
./memsafety-ext / skiplist_21vLtrue-valid-meinsafety.i 
./memsafety-ext / skiplist_31vl_true-valid-memsafety.i 
. /memsafety-ext / tree _cnstr_true-valid-memsafety.i 
. /memsafety-ext / tree_dsw_true-valid-memsafety. i 
. /memsafety-ext / tree _of_cslls_true-valid-memsafety. i 
./memsafety-ext/tree_parent_ptr_true-valid-memsafety.i 
. /memsafety-ext / tree _stack_true-valid-memsafety. i 
. /memsafety /960521-1 _false-valid-free, i 
./memsafety/lockfree-3.0_true-valid-memsafety.i 
./memsafety/lockfree-3.3_false-valid-memtrack.i 
./memsafety/test-0019_false-valid-memtrack.i 
./memsafety/test-0137_false-valid-deref.i 
./memsafety/test-0158_false-valid-memtrack.i 
. /memsafety /test-0219_true-valid-memsafety. i 
./memsafety/test-0220_false-valid-memtrack.i 
./memsafety/test-0236_true-valid-memsafety.i 
./memsafety/test-0504_true-valid-memsafety.i 

./ntdrivers-simplified/cdaudio_simpll_false-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/cdaudio_simpll_true-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/diskperf_simpll_true-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/floppy_simpl3_false-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/floppy_simpl3_true-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/floppy_simpl4_false-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/floppy_simpl4_true-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/kbfiltr_simpll_true-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/kbfiltr_simpl2_false-unreach-calLtrue-termination.cil.c 

./ntdrivers-simplified/kbfiltr_simpl2_true-unreach-calLtrue-termination.cil.c 

. /nt drivers/cdaudio-false-unreach-call. i. cil. c 

. /ntdrivers/cdaudio_t rue-unreach-call. i. cil. c 

./ntdrivers/diskperLfalse-unreach-call.i.cil.c 

./ntdrivers/diskperLtrue-unreach-call.i.cil.c 

. /nt drivers/floppy2 _true-unreach-call. i. cil. c 

. /nt drivers/floppy _false-unreach-call. i. cil. c 

. /ntdrivers/floppy-true-unreach-call. i. cil. c 

./ntdrivers/kbfiltr_false-unreach-call.i.cil.c 

./ntdrivers/parport_false-unreach-call.i.cil.c 

./ntdrivers/parport_true-unreach-call.i.cil.c 

./product-lines/elevator_specl3_product21_true-unreach-call.cil.c 

./product-lines/emaiLspec3_productl9_false-unreach-call.cil.c 
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./product-lines/einaiLspec4_productl7_true-unreach-call.cil.c 
./product-lines/einaiLspec6_productl5_false-unreach-call.cil.c 
./product-lines/emaiLspec9_product21_false-unreach-call.cil.c 
./product-lines/minepump_spec2_product34_false-unreach-call.cil.c 
./product-lines/minepump_spec2_product38_true-unreach-call.cil.c 
./product-lines/niinepump_spec2_product60_true-unreach-call.cil.c 
./product-lines/niinepump_spec5_product20_true-unreach-call.cil.c 
./product-lines/niinepump_spec5_product61_true-unreach-call.cil.c 
./pthread-atomic/dekker_true-unreach-call.i 
./pthread-atomic/lamport_true-unreach-call.i 
./pthread-atomic/peterson_true-unreach-call.i 
./pthread-atomic/qrcu_false-unreach-call.i 
./pthread-atomic/qrcu_true-unreach-call.i 
./pthread-atomic/read_write_lock_false-unreach-call.i 
./pthread-atomic/read_writeJock_true-unreach-call.i 
./pthread-atomic/sculLtrue-unreach-call.i 
. /pthread-atomic/szymanski_true-unreach-call.i 
./pthread-atomic/time_var_mutex_true-unreach-call.i 
./pthread-ext/01_inc_true-unreach-call.i 
./pthread-ext/04_incdec_cas_true-unreach-call.i 
./pthread-ext/05_tas_true-unreach-call, i 
./pthread-ext/08_rand_cas_true-unreach-call.i 
./pthread-ext/18_read_writeJock_true-unreach-call.i 
./pthread-ext/19_time_var_niutex_true-unreach-call.i 
./pthread-ext/23_lu-fig2.fixed_true-unreach-call.i 
./pthread-ext/25_stack_longest_true-unreach-call.i 
./pthread-ext/27_Boop_simple_vf_false-unreach-call.i 
./pthread-ext/30_Function_Pointer3_vs_true-unreach-call.i 
./pthread-lit/lk2012_true-unreach-call.i 
./pthread-lit/lkp2013_false-unreach-call.i 
./pthread-lit/lkp2013_true-unreach-call.i 
./pthread-lit/fkp2013_variant_true-unreach-call.i 
./pthread-lit/lkp2014_true-unreach-call.i 
./pthread-lit/qw2004_false-unreach-call.i 
./pthread-lit/qw2004_true-unreach-call.i 
./pthread-lit/qw2004_variant_true-unreach-call.i 
./pthread-lit/ssscl2_true-unreach-call.i 
./pthread-lit/ssscl2_variant_true-unreach-call.i 
./pthread-wmm/mixOOO_power.oepc_false-unreach-call.i 
./pthread-wmm/mix008_pso.oepc_false-unreach-call.i 
./pthread-wmm/mix041_power.oepc_false-unreach-call.i 
./pthread-wmm/mix054_tso.opt_false-unreach-call.i 
./pthread-wmm/mix055_power.opt_false-unreach-call.i 
./pthread-wmm/rfi009_rmo.oepc_false-unreach-call.i 
. /pt bread-wmm/rfi009_rmo. opt _false-unreach-call. i 
./pthread-wmm/rfi009_tso.oepc_false-unreach-call.i 
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./pthread-wmm/safe037_tso.oepc_true-unreach-call.i 
./pthread-wmm/thin002_pso.oepc_true-unreach-call.i 
./pthread/fib_bench_longer_false-unreach-call.i 
./pthread/fib_benchdonger_true-unreach-call.i 
./pthread/fib-benchJongest-true-unreach-call.i 
. /pt bread / queue .longest .false-unreach-call. i 
./pthread/queue.ok.longer.true-unreach-call.i 
./pthread/queue_okdongest_true-unreach-call.i 
./pthread/queue.ok.true-unreach-call.i 
. /pthread / sigma.false-unreach-call, i 
. /pthread / singlet on_false-unreach-call. i 
. /pthread / st atefulO 1 _false-unreach-call. i 
./recursive-simple/afterrec.2calls.false-unreach-call.c 
./recursive-simple/afterrec.true-unreach-call.c 
./recursive-simple/fibo_2calls_2 .false-unreach-call.c 
./recursive-simple/fibo.2calls.5 .false-unreach-call.c 
./recursive-simple/id.b5.ol0.true-unreach-call.c 
./recursive-simple/id.il0.ol0.true-unreach-call.c 
./recursive-simple/id_olO_false-unreach-call.c 
./recursive-simple/id.o200.false-unreach-call.c 
./recursive-simple/sum.2x3.false-unreach-call.c 
. /recursive-simple / sum.non.true-unreach-call.c 
./recursive/Ackermann03_true-unreach-call.c 
./recursive/AdditionOl.true-unreach-call.true-termination.c 
./recursive/Addition03.false-unreach-call.c 
./recursive/EvenOdd03_false-unreach-call_false-termination.c 
. /recursive/FibonacciOl .true-unreach-call, c 
./recursive/Fibonacci02.true-unreach-call.true-termination.c 
./recursive/McCarthyQl.true-unreach-call.c 
./recursive/Primes.true-unreach-call.c 
. / recursive/gcd02 .t rue-unreach-call. c 

./recursive/recHanoi03.true-unreach-call.true-termination.c 

./seq-mthreaded/pals.STARTPALS.Triplicated.true-unreach-call.ufo.BOUNDFD- 
10.pals.c 

./seq-mthreaded/pals.floodmax.5.true-unreach-call.ufo.BOUNDFD-10.pals.c 

./seq-mthreaded/pals.lcr.7.true-unreach-call.ufo.UNBOUNDED.pals.c 

./seq-mthreaded/pals.opt-floodmax.5.false-unreach-call.l.ufo.BOUNDED-10.pals.c 

./seq-mthreaded/pals.opt-floodmax.5.false-unreach-call.l.ufo.UNBOUNDED.pals.c 

./seq-mthreaded/pals.opt-floodmax.5.false-unreach-call.2.ufo.BOUNDED-10.pals.c 

./seq-mthreaded/rekh.ctm.true-unreach-call.2.c 

./seq-mthreaded/rekh.ctm.true-unreach-call.4.c 

./seq-mthreaded/rekh.nxt .false-unreach-call.2.M4.C 

./seq-mthreaded/rekh.nxt.true-unreach-call.3.Ml.c 

. /seq-pthread/cs.fib .longer .false-unreach-call, i 

. / seq-pthread / cs.fib .longer .true-unreach-call, i 

./seq-pthread/cs.fib.true-unreach-call.i 
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. / seq-pthread / cs Jamport _t rue-unreach-call. i 
. / seq-pthread / cs_peterson_true-unreach-call, i 
./seq-pthread/cs_queue_false-unreach-call.i 
./seq-pthread/cs_stack_false-unreach-call.i 
./seq-pthread/cs_statefuLfalse-unreach-call.i 
. / seq-pthread / cs_sync_true-unreach-call, i 
./seq-pthread/cs_szymanski_true-unreach-call.i 
./ssh-simplified/s3_clnt_l_true-unreach-call.cil.c 
./ssh-simplified/s3_clnt_2_true-unreach-call_true-termination.cil.c 
. / ssh-simplified/s3 _clnt _4_false-unreach-call. cil. c 
. / ssh-simplified/s3 _clnt _4_t rue-unreach-call. cil.c 
./ssh-simplified/s3_srvr_ll_false-unreach-call.cil.c 
./ssh-simplified/s3_srvr_14_false-unreach-call.cil.c 
. / ssh-simplified/s3 _srvr_l _false-unreach-call. cil. c 
. / ssh-simplified/s3 _srvr_l _t rue-unreach-call. cil. c 
. / ssh-simplified/s3 _srvr_4_t rue-unreach-call. cil. c 
. /ssh-simplified/s3 _srvr_6_t rue-unreach-call. cil. c 
. /ssh/s3 _srvr .blast. 01 _true-unreach-call. i .cil.c 
./ssh/s3_srvr.blast.02_false-unreach-call.i.cil.c 
./ssh/s3_srvr.blast.03_false-unreach-call.i.cil.c 
./ssh/s3_srvr.blast.04_false-unreach-call.i.cil.c 
./ssh/s3_srvr.blast.06_true-unreach-call.i.cil.c 
./ssh/s3_srvr.blast.07_true-unreach-call.i.cil.c 
./ssh/s3_srvr.blast.08_false-unreach-call.i.cil.c 
. /ssh/s3 _srvr .blast. 10 _true-unreach-call. i .cil.c 
. /ssh/s3 _srvr .blast. 12 _true-unreach-call. i .cil.c 
./ssh/s3_srvr.blast. 13_false-unreach-call.i.cil.c 
./systemc/kundu2_false-unreach-calLfalse-termination.cil.c 
./systemc/kundu_true-unreach-calLfalse-termination.cil.c 
./systemc/pc_sfifo_2_false-unreach-calLfalse-termination.cil.c 
./systemc/token_ring.03_false-unreach-calLfalse-termination.cil.c 
./systemc/token_ring.l2_true-unreach-calLfalse-termination.cil.c 
./systemc/token_ring.l3_false-unreach-calLfalse-termination.cil.c 
. / systemc/token_ring. 14_false-unreach-calLfalse-termination.cil.c 
./systemc/toy2_false-unreach-calLfalse-termination.cil.c 
./systemc/toy-true-unreach-calLfalse-termination.cil.c 
./systemc / transmitter. 12_false-unreach-calLfalse-termination.cil.c 

./termination-craft ed-lit/AliasDarteFeautrierGonnord-SAS2010-Fig2a_true-termination.c 
./termination-craft ed-lit/HeizmannHoenickeLeikePodelski-ATVA2013-Figl_true- 
termination.c 

./termination-craft ed-lit/LarrazOliverasRodriguez-CarbonellRubio-FMC AD2013- 
F igl _true-terminat ion. c 

./termination-craft ed-lit/PodelskiRybalchenko-TACAS2011-Fig4_true-termination.c 
./termination-craft ed-lit/PodelskiRybalchenko-VMCAI2004-Exl_true-termination.c 
./termination-craft ed-lit/Velroyen_false-termination.c 
./termination-crafted-lit / cstrcspnArue-termination.c 
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./terminatioii-crafted-lit / cstrpbrk_true-termination.c 

./termination-crafted-lit / cstrspn_true-termination.c 

./termination-craft ed-lit/gcdl_true-termination.c 

./termination-craft ed/4BitCounterPointer_true-termination.c 

./termination-craft ed/Cairo_true-termination.c 

. /termination-crafted / Copenhagen_true-termination.c 

./termination-craft ed/NonTermination3_false-termination.c 

./termination-craft ed/NonTermination4_false-termination.c 

./termination-craft ed/NonTerminationSimple9_false-termination.c 

./termination-craft ed/ParalleLtrue-termination.c 

./termination-crafted/Pure2Phase_true-termination.c 

./termination-craft ed/RecursiveNonterminating_false-termination.c 

./termination-craft ed/Stockholm_true-termination.c 

./termination-inemory-alloca/b.09_assume-alloca_true-termination.c.i 

./termination-memory-alloca/b.lO-alloca_true-termination.c.i 

./termination-memory-alloca/b.l3-alloca_true-termination.c.i 

./termination-memory-alloca/cstrncat-alloca_true-termination.c.i 

./termination-memory-alloca/java_Break-alloca_true-termination.c.i 

./termination-memory-alloca/java_LogBuiltIn-alloca_true-termination.c.i 

./termination-memory-alloca/java_Nested-alloca_true-termination.c.i 

./termination-memory-alloca/java_Sequence-alloca_true-termination.c.i 

./termination-memory-alloca/openbsd_cbzero-alloca_true-termination.c.i 

./termination-memory-alloca/openbsd_cstrcmp-alloca_true-termination.c.i 

./termination-numeric/Avg_true_true-termination.c 

./termination-numeric/BinomiaLtrue-termination.c 

. /termination-numeric/Et 1 _true_true-termination.c 

./termination-numeric/Parts_true-termination.c 

./termination-numeric/Two Way-true-termination.c 

./termination-numeric/b.03-no-inv_assume_true-termination.c 

. /termination-numeric / easySum_true-termination.c 

./termination-numeric/java_LogBuiltIn_true-termination.c 

./termination-numeric/java_Nested_true-termination.c 

./termination-numeric/rec_counterl_true-termination.c 
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